[Xen-devel] [qemu-upstream-4.4-testing baseline-only test] 44411: tolerable FAIL

This run is configured for baseline tests only. flight 44411 qemu-upstream-4.4-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44411/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-credit2 19

Re: [Xen-devel] [PATCH v4 09/10] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU suspending

On May 10, 2016 5:25 PM, Jan Beulich wrote: > >>> On 06.05.16 at 10:54, wrote: > > --- a/xen/arch/x86/acpi/power.c > > +++ b/xen/arch/x86/acpi/power.c > > static int device_power_down(void) > > { > > -console_suspend(); > > +if ( console_suspend()

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

Hi Tianyang 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. > > Use non-atomic bit-ops: > -Vcpu flags are checked and cleared atomically. Performance can be > improved

[Xen-devel] [xen-unstable test] 94050: regressions - trouble: blocked/broken/fail/pass

flight 94050 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/94050/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl3 host-install(3) broken REGR. vs. 94021

[Xen-devel] [libvirt test] 94052: regressions - FAIL

flight 94052 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/94052/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw 6 xen-boot fail REGR. vs. 94018 Tests which did not

[Xen-devel] Question about MMU update on HVM guest

Hi, I have some questions about MMU update operation. I add some logging in function *do_mmu_update* (in file /xen/arch/x86/mm.c), and start Windows 7 32 bit HVM guest. After guest started, I look at log and see that MMU update has been called with every page of guest, with *pt_ower = 0* and

[Xen-devel] [qemu-upstream-4.4-testing test] 94048: tolerable FAIL - PUSHED

flight 94048 qemu-upstream-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94048/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-pv 17 guest-localmigrate/x10 fail in 94023 pass in 94048

[Xen-devel] [xen-4.4-testing test] 94038: regressions - FAIL

flight 94038 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94038/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xend-qemut-winxpsp3 9 windows-installfail REGR. vs. 92242 Regressions

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

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 deal with > this part of the bug. Something like

[Xen-devel] [linux-4.1 baseline-only test] 44410: regressions - trouble: blocked/broken/fail/pass

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

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

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

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

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

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

flight 94060 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/94060/ 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] [TESTDAY] Test report - xl sched-rtds

* 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 per-VCPU parameters) * Comments: All examples about "xl sched-rtds" in xl mannual

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

flight 94037 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/94037/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail REGR. vs. 93937

Re: [Xen-devel] [PATCH-for-4.7 1/2] xendriverdomain: use POSIX sh and not bash

On Thu, May 12, 2016 at 04:56:30PM +0100, Wei Liu wrote: > On Thu, May 12, 2016 at 10:29:29AM -0500, Doug Goldstein wrote: > > The script doesn't use any bash-isms and works fine with BusyBox's ash. > > > > Signed-off-by: Doug Goldstein > > Acked-by: Wei Liu

Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

>-Original Message- >From: Tamas K Lengyel [mailto:tamas.k.leng...@gmail.com] >Sent: Thursday, May 12, 2016 8:54 AM >To: Wei Liu >Cc: Big Strong ; Sahita, Ravi ; >White, Edmund H ; Jan Beulich

Re: [Xen-devel] [PATCH-for-4.7 1/2] xendriverdomain: use POSIX sh and not bash

On Thu, May 12, 2016 at 10:29:29AM -0500, Doug Goldstein wrote: > The script doesn't use any bash-isms and works fine with BusyBox's ash. > > Signed-off-by: Doug Goldstein Acked-by: Wei Liu Release-acked-by: Wei Liu > --- >

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

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > David Miller > Sent: 12 May 2016 16:52 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; net...@vger.kernel.org > Subject: Re: [Xen-devel] [PATCH net-next v2 0/4] xen-netback: support for

Re: [Xen-devel] [PATCH 2/2] xendriverdomain: don't depend on legacy /proc/xen

On Thu, May 12, 2016 at 10:29:30AM -0500, Doug Goldstein wrote: > xl devd prefers to use /dev/xen/ instead of /proc/xen so the init script > should use the new interface as well and drop the legacy interface. To > check for support this uses /sys/hypervisor which has been present since > 2.6.18

Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

On Thu, May 12, 2016 at 9:17 AM, Wei Liu wrote: > On Thu, May 12, 2016 at 09:00:12PM +0800, Big Strong wrote: >> I'm still not very clear why would do_altp2m_op change the domain to >> current domain (which is dom0 in my case) when the cmd is >>

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

From: Paul Durrant Date: Wed, 11 May 2016 16:16:26 +0100 > 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

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

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 at 0 when runstate is INMIGRATE xen_ram_alloc: do not alloc 80

[Xen-devel] [PATCH-for-4.7 1/2] xendriverdomain: use POSIX sh and not bash

The script doesn't use any bash-isms and works fine with BusyBox's ash. Signed-off-by: Doug Goldstein --- tools/hotplug/Linux/init.d/xendriverdomain.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/hotplug/Linux/init.d/xendriverdomain.in

Re: [Xen-devel] Please reconsider bug 26

Hello On Wed, May 11, 2016 at 04:51:41PM +0200, Sébastien Chaumat wrote: > Hello, > > http://bugs.xenproject.org/xen/bug/26 is nearly 3yrs old. > > (bassically one can attach the same vbd rw to 2 domUs with xl without > warning ) > > Combined with a distribution behavior like > >

[Xen-devel] [linux-3.14 baseline-only test] 44408: regressions - FAIL

This run is configured for baseline tests only. flight 44408 linux-3.14 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44408/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 15

[Xen-devel] [PATCH 2/2] xendriverdomain: don't depend on legacy /proc/xen

xl devd prefers to use /dev/xen/ instead of /proc/xen so the init script should use the new interface as well and drop the legacy interface. To check for support this uses /sys/hypervisor which has been present since 2.6.18 Xen kernels. Fix bad whitespace at the same time. Signed-off-by: Doug

[Xen-devel] [PATCH v3 2/2] tests/mem-sharing: Add bulk option to memshrtool

Add the bulk option to the test tool to perform complete deduplication between domains. Signed-off-by: Tamas K Lengyel Acked-by: Wei Liu --- Cc: Ian Jackson Cc: Stefano Stabellini Cc: Ian

[Xen-devel] [xen-4.6-testing test] 94036: trouble: broken/fail/pass

flight 94036 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94036/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 3 host-install(3) broken REGR. vs.

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

Currently mem-sharing can be performed on a page-by-page base from the control domain. However, when completely deduplicating (cloning) a VM, this requires at least 3 hypercalls per page. As the user has to loop through all pages up to max_gpfn, this process is very slow and wasteful. This patch

Re: [Xen-devel] [PATCH v5 2/3] xen: write information about supported backends

On Thu, May 12, 2016 at 04:13:40PM +0200, Juergen Gross wrote: > Add a Xenstore directory for each supported pv backend. This will allow > Xen tools to decide which backend type to use in case there are > multiple possibilities. > > The information is added under >

Re: [Xen-devel] [PATCH v5 1/3] xen: introduce dummy system device

On Thu, May 12, 2016 at 04:13:39PM +0200, Juergen Gross wrote: > Introduce a new dummy system device serving as parent for virtual > buses. This will enable new pv backends to introduce virtual buses > which are removable again opposed to system buses which are meant > to stay once added. > >

Re: [Xen-devel] [libvirt] [PATCH 1/3] libxl: switch to using libxl_domain_create_restore from v4.4 API

Olaf Hering wrote: > On Wed, May 11, Jim Fehlig wrote: > >> https://www.redhat.com/archives/libvir-list/2016-May/msg00686.html > > Perhaps configure.ac should be changed to reject libxl upfront. Yes, good idea. > It looks > like the assignment of LIBXL_CFLAGS should be moved up, so that >

Re: [Xen-devel] [PATCH] x86/PoD: skip eager reclaim when possible

On 12/05/16 16:08, Jan Beulich wrote: On 12.05.16 at 16:40, wrote: >> On 10/05/16 14:44, Jan Beulich wrote: >>> Reclaiming pages is pointless when the cache can already satisfy all >>> outstanding PoD entries, and doing reclaims in that case can be very >>> harmful

Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

On Thu, May 12, 2016 at 09:00:12PM +0800, Big Strong wrote: > I'm still not very clear why would do_altp2m_op change the domain to > current domain (which is dom0 in my case) when the cmd is > HVMOP_altp2m_vcpu_enable_notify >

Re: [Xen-devel] [PATCH] x86/PoD: skip eager reclaim when possible

>>> On 12.05.16 at 16:40, wrote: > On 10/05/16 14:44, Jan Beulich wrote: >> Reclaiming pages is pointless when the cache can already satisfy all >> outstanding PoD entries, and doing reclaims in that case can be very >> harmful to performance when that memory gets used

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

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

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

>>> 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 wrote: >> >> >>> On 06.05.16 at 10:54,

Re: [Xen-devel] [PATCH] x86/PoD: skip eager reclaim when possible

On 10/05/16 14:44, Jan Beulich wrote: > Reclaiming pages is pointless when the cache can already satisfy all > outstanding PoD entries, and doing reclaims in that case can be very > harmful to performance when that memory gets used by the guest, but > only to store zeroes there. > >

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

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 wrote: > >> >>> On 06.05.16 at 10:54, wrote: > For DomU the solution seems quite obvious: Only

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

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, May 12, 2016 9:51 AM > To: Zytaruk, Kelly > Cc: Feng Wu; Kevin Tian; xen-devel@lists.xen.org > Subject: RE: [Xen-devel] panic("queue invalidate wait descriptor was not > executed\n") > > >>> On

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

On 12/05/16 15:52, Gerd Hoffmann wrote: > On Do, 2016-05-12 at 07:47 +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

Re: [Xen-devel] [PATCH net] xen-netback: fix extra_info handling in xenvif_tx_err()

On Thu, May 12, 2016 at 02:43:03PM +0100, Paul Durrant wrote: > Patch 562abd39 "xen-netback: support multiple extra info fragments > passed from frontend" contained a mistake which can result in an in- > correct number of responses being generated when handling errors > encountered when processing

[Xen-devel] [PATCH v5 3/3] xen: add pvUSB backend

Add a backend for para-virtualized USB devices for xen domains. The backend is using host-libusb to forward USB requests from a domain via libusb to the real device(s) passed through. Signed-off-by: Juergen Gross Acked-by: Anthony PERARD --- V3:

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

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 backend with various USB devices (memory sticks, keyboard, ...).

[Xen-devel] [PATCH v5 1/3] xen: introduce dummy system device

Introduce a new dummy system device serving as parent for virtual buses. This will enable new pv backends to introduce virtual buses which are removable again opposed to system buses which are meant to stay once added. Signed-off-by: Juergen Gross Acked-by: Anthony PERARD

[Xen-devel] [PATCH v5 2/3] xen: write information about supported backends

Add a Xenstore directory for each supported pv backend. This will allow Xen tools to decide which backend type to use in case there are multiple possibilities. The information is added under /local/domain//device-model//backends before the "running" state is written to Xenstore. Using a directory

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

> -Original Message- [snip] > > > > Ok. Do you regard this as a critical issue for 4.7? > > > > Our general support statement is to support N->N+1 migration, so it is > not really critical for me. On the other hand, if the fix is not overly > complex, it would be nice to have for 4.7. >

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

On Thu, May 12, 2016 at 02:03:31PM +0100, Paul Durrant wrote: > > -Original Message- > > From: Wei Liu [mailto:wei.l...@citrix.com] > > Sent: 12 May 2016 14:02 > > To: Paul Durrant > > Cc: Wei Liu; Andrew Cooper; Olaf Hering; xen-devel@lists.xen.org; Anthony > > Perard; Stefano Stabellini

[Xen-devel] [PATCH net] xen-netback: fix extra_info handling in xenvif_tx_err()

Patch 562abd39 "xen-netback: support multiple extra info fragments passed from frontend" contained a mistake which can result in an in- correct number of responses being generated when handling errors encountered when processing packets containing extra info fragments. This patch fixes the

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

On Do, 2016-05-12 at 07:47 +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")

>>> On 12.05.16 at 14:36, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: Thursday, May 12, 2016 5:49 AM >> >>> On 11.05.16 at 15:51, wrote: >> > During Xen boot I am seeing the panic in the subject line from >> >

Re: [Xen-devel] [PATCH v4 01/10] vt-d: fix the IOMMU flush issue

On May 12, 2016 9:38 PM, Jan Beulich wrote: > >>> On 12.05.16 at 15:29, wrote: > > On May 12, 2016 4:53 PM, Jan Beulich wrote: > >> >>> On 12.05.16 at 09:50, wrote: > >> > On May 10, 2016 12:10 AM, Jan Beulich

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

On Thu, 12 May 2016, Wei Liu wrote: > On Thu, May 12, 2016 at 01:39:49PM +0100, Paul Durrant wrote: > > > -Original Message- > > > From: Wei Liu [mailto:wei.l...@citrix.com] > > > Sent: 12 May 2016 11:56 > > > To: Paul Durrant > > > Cc: Andrew Cooper; Olaf Hering; xen-devel@lists.xen.org;

Re: [Xen-devel] [PATCH v4 01/10] vt-d: fix the IOMMU flush issue

>>> On 12.05.16 at 15:29, wrote: > On May 12, 2016 4:53 PM, Jan Beulich wrote: >> >>> On 12.05.16 at 09:50, wrote: >> > On May 10, 2016 12:10 AM, Jan Beulich wrote: >> >> >>> On 06.05.16 at 10:54,

Re: [Xen-devel] [PATCH v4 01/10] vt-d: fix the IOMMU flush issue

On May 12, 2016 4:53 PM, Jan Beulich wrote: > >>> On 12.05.16 at 09:50, wrote: > > On May 10, 2016 12:10 AM, Jan Beulich wrote: > >> >>> On 06.05.16 at 10:54, wrote: > >> > -static void intel_iommu_iotlb_flush(struct

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

On Thu, May 12, Paul Durrant wrote: > Ok. Do you regard this as a critical issue for 4.7? I do, coming from 4.4 ;-) Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

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

> -Original Message- > From: Wei Liu [mailto:wei.l...@citrix.com] > Sent: 12 May 2016 14:02 > To: Paul Durrant > Cc: Wei Liu; Andrew Cooper; Olaf Hering; xen-devel@lists.xen.org; Anthony > Perard; Stefano Stabellini > Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in

[Xen-devel] [PATCH V2] xen/arm: mm: fix nr_second calculation in setup_frametable_mappings

On ARM64, "frametable_size >> SECOND_SHIFT" computes the number of second level entries, not the number of second level pages. "ROUNDUP(frametable_size, FIRST_SIZE) >> FIRST_SHIFT" which computes the number of the first level entries (the number of second level pages), is the correct one that

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

On Thu, May 12, 2016 at 01:39:49PM +0100, Paul Durrant wrote: > > -Original Message- > > From: Wei Liu [mailto:wei.l...@citrix.com] > > Sent: 12 May 2016 11:56 > > To: Paul Durrant > > Cc: Andrew Cooper; Olaf Hering; xen-devel@lists.xen.org; Wei Liu > > Subject: Re: [Xen-devel] live

Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

I'm still not very clear why would do_altp2m_op change the domain to current domain (which is dom0 in my case) when the cmd is HVMOP_altp2m_vcpu_enable_notify . As to my

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

> -Original Message- > From: Wei Liu [mailto:wei.l...@citrix.com] > Sent: 12 May 2016 11:56 > To: Paul Durrant > Cc: Andrew Cooper; Olaf Hering; xen-devel@lists.xen.org; Wei Liu > Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq > server > > On Wed, May 11, 2016

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

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, May 12, 2016 5:49 AM > To: Zytaruk, Kelly > Cc: Feng Wu; Kevin Tian; xen-devel@lists.xen.org > Subject: Re: [Xen-devel] panic("queue invalidate wait descriptor was not > executed\n") > > >>> On

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

flight 94035 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/94035/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 fail REGR. vs. 92982

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

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 parameters under /chosen and /hyperviosr/uefi are not expected to appear at the same time. Parse these EFI

[Xen-devel] [linux-4.1 test] 94034: tolerable FAIL - PUSHED

flight 94034 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/94034/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeatfail like 93111 test-armhf-armhf-xl-rtds 15

Re: [Xen-devel] [PATCH] xen/arm: mm: fix nr_second calculation in setup_frametable_mappings

On 12/05/16 12:30, Peng Fan wrote: Hi Julien, On Thu, May 12, 2016 at 11:48:30AM +0100, Julien Grall wrote: Hi Peng, On 12/05/16 07:36, Peng Fan wrote: To ARM64, "frametable_size >> SECOND_SHIFT" means the number of second level entries, not the number of second level pages.

[Xen-devel] [PATCH V3 1/2] xen/arm: mm: remove unnecessary tlb flush in setup_pagetables

CPU0 is using the boot pages table before relocating xen and xen_second is not part of them. So, no need to flush the TLB when filling xen_second. Signed-off-by: Peng Fan Cc: Stefano Stabellini Cc: Julien Grall Reviewed-by:

[Xen-devel] [PATCH V3 2/2] xen/arm: mm: clean up code in setup_pagetables

The base of address for the relocated xen needs to be mapped at the same virtual address (BOOT_RELOC_VIRT_START) in both the boot and runtime page tables. So we can merge the two pieces of code into on code block Also no need to use write_pte when mapping BOOT_RELOC_VIRT_START in xen_second,

Re: [Xen-devel] [PATCH] xen/arm: mm: fix nr_second calculation in setup_frametable_mappings

Hi Julien, On Thu, May 12, 2016 at 11:48:30AM +0100, Julien Grall wrote: >Hi Peng, > >On 12/05/16 07:36, Peng Fan wrote: >>To ARM64, "frametable_size >> SECOND_SHIFT" means the number >>of second level entries, not the number of second level pages. >> >>"DIV_ROUND_UP(frametable_size >>

Re: [Xen-devel] [PATCH] v3 - Add exclusive locking option to block-iscsi

Hi Steven On Mon, May 09, 2016 at 02:22:48PM +1000, Steven Haigh wrote: > On 2016-05-05 15:52, Steven Haigh wrote: > >On 2016-05-05 12:32, Steven Haigh wrote: > >>Overview > >> > >>If you're using iSCSI, you can mount a target by multiple Dom0 > >>machines on the same target. For non-cluster

Re: [Xen-devel] [PATCH V2 2/2] xen/arm: mm: clean up code in setup_pagetables

Hi Peng, Hi Peng, On 12/05/16 03:01, Peng Fan wrote: In setup_pagetables, need to map BOOT_RELOC_VIRT_START in xen_second and boot_second, so we can merge the two pieces code into one code block. There is a missing subject for "need". I would say: "The base of address for the relocated xen

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

On Thu, 12 May 2016, Matt Fleming wrote: > On Thu, 12 May, at 10:22:07AM, Shannon Zhao wrote: > > > > As said above, I will rebase this patch on top of the EFI next branch. > > OK thanks. > > Note that it is not possible to escape merge conflicts, since there > are changes in the xen tip tree

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

On Wed, May 11, 2016 at 12:38:46PM +, Paul Durrant wrote: > > -Original Message- > > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > > Sent: 11 May 2016 13:23 > > To: Olaf Hering; xen-devel@lists.xen.org; Paul Durrant > > Subject: Re: [Xen-devel] live migrating hvm from 4.4 to

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

On Wed, May 11, 2016 at 03:07:16PM +0200, Olaf Hering wrote: > On Wed, May 11, Olaf Hering wrote: > > > Migration from staging-4.4 to staging-4.6 fails in the same way. We did > > not have a 4.6 based Xen, so noone noticed until now. > > And migration from staging-4.5 to staging works as well.

Re: [Xen-devel] [PATCH V2 1/2] xen/arm: mm: remove unnecessary tlb flush in setup_pagetables

Hi Peng, On 12/05/16 03:01, Peng Fan wrote: CPU0 is using the boot pages table before relocating xen and xen_second is not part of them. So, no need to flush the TLB when filling xen_second. Signed-off-by: Peng Fan Cc: Stefano Stabellini Cc:

Re: [Xen-devel] [PATCH] xen/arm: mm: fix nr_second calculation in setup_frametable_mappings

Hi Peng, On 12/05/16 07:36, Peng Fan wrote: To ARM64, "frametable_size >> SECOND_SHIFT" means the number of second level entries, not the number of second level pages. "DIV_ROUND_UP(frametable_size >> SECOND_SHIFT, LPAE_ENTRIES)" is the correct way to calculate the second level pages needed

[Xen-devel] [xen-unstable baseline-only test] 44407: regressions - trouble: blocked/broken/fail/pass

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

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

On 12/05/16 10:40, He Chen wrote: > % Intel L2 Cache Allocation Technology (L2 CAT) Feature > % Revision 1.0 > > \clearpage > > Hi all, > > We plan to bring new PQoS feature called Intel L2 Cache Allocation > Technology (L2 CAT) to Xen. > > L2 CAT is supported on Atom codename Goldmont and beyond.

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

>>> On 12.05.16 at 11:40, wrote: > % Intel L2 Cache Allocation Technology (L2 CAT) Feature > % Revision 1.0 > > \clearpage > > Hi all, > > We plan to bring new PQoS feature called Intel L2 Cache Allocation > Technology (L2 CAT) to Xen. > > L2 CAT is supported on Atom

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

On Thu, 12 May, at 10:22:07AM, Shannon Zhao wrote: > > As said above, I will rebase this patch on top of the EFI next branch. OK thanks. Note that it is not possible to escape merge conflicts, since there are changes in the xen tip tree that are not in the EFI next branch and vice versa. For

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

flight 94030 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94030/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 93989

Re: [Xen-devel] [PATCH v4 2/3] xen: write information about supported backends

On Thu, May 12, 2016 at 07:47:46AM +0200, Juergen Gross wrote: > Add a Xenstore directory for each supported pv backend. This will allow > Xen tools to decide which backend type to use in case there are > multiple possibilities. > > The information is added under >

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

>>> On 11.05.16 at 15:51, wrote: > During Xen boot I am seeing the panic in the subject line from > .../xen/drivers/passthrough/vgt/qinval.c And this is with current staging, or some much older version of Xen? (ISTR some issue with the invalidation request getting sent to

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

% Intel L2 Cache Allocation Technology (L2 CAT) Feature % Revision 1.0 \clearpage Hi all, We plan to bring new PQoS feature called Intel L2 Cache Allocation Technology (L2 CAT) to Xen. L2 CAT is supported on Atom codename Goldmont and beyond. “Big-core” Xeon does not support L2 CAT in current

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

% Intel L2 Cache Allocation Technology (L2 CAT) Feature % Revision 1.0 \clearpage Hi all, We plan to bring new PQoS feature called Intel L2 Cache Allocation Technology (L2 CAT) to Xen. L2 CAT is supported on Atom codename Goldmont and beyond. “Big-core” Xeon does not support L2 CAT in current

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

Hi Meng, On Thu, May 12, 2016 at 6:30 AM, Meng Xu wrote: > Hi Dushyant, > > On Tue, Mar 8, 2016 at 3:23 AM, Dushyant K Behl > wrote: > > May I know which u-boot repo and which branch you used to enable the > non-secure mode? If you could also

Re: [Xen-devel] [PATCH v3 5/6] build: convert perfc{, _arrays} to Kconfig

>>> On 11.05.16 at 20:39, wrote: > On 5/11/16 4:53 AM, Jan Beulich wrote: > On 10.05.16 at 23:05, wrote: >>> Convert the 'perfc' and 'perfc_arrays' options to Kconfig as >>> CONFIG_PERF_COUNTERS and CONFIG_PERF_ARRAYS to minimize code changes. >> >> I

Re: [Xen-devel] [PATCH v3 3/6] build: convert verbose to Kconfig

>>> On 11.05.16 at 19:37, wrote: > On 5/11/16 4:45 AM, Jan Beulich wrote: > On 10.05.16 at 23:05, wrote: >>> --- a/xen/Kconfig.debug >>> +++ b/xen/Kconfig.debug >>> @@ -15,4 +15,11 @@ config DEBUG >>> option is intended for development purposes

Re: [Xen-devel] [PATCH v3 2/6] build: convert crash_debug to Kconfig

>>> On 11.05.16 at 19:35, wrote: > On 5/11/16 4:47 AM, Jan Beulich wrote: > On 10.05.16 at 23:05, wrote: >>> --- a/xen/Kconfig.debug >>> +++ b/xen/Kconfig.debug >>> @@ -1,6 +1,13 @@ >>> >>> menu "Debugging Options" >>> >>> +config CRASH_DEBUG >>> +

Re: [Xen-devel] [PATCH v4 10/10] vt-d: propagate error up to ME phantom function mapping and unmapping

On May 12, 2016 4:45 PM, Jan Beulich wrote: > >>> On 12.05.16 at 07:16, wrote: > > Taken together, there are 3 call trees to me_wifi_quirk(): > > > > 1). > > ...--me_wifi_quirk()--domain_context_mapping_one()-- > domain_context_map > > ping()--se > >

Re: [Xen-devel] [PATCH v4 01/10] vt-d: fix the IOMMU flush issue

>>> On 12.05.16 at 09:50, wrote: > On May 10, 2016 12:10 AM, Jan Beulich wrote: >> >>> On 06.05.16 at 10:54, wrote: >> > -static void intel_iommu_iotlb_flush(struct domain *d, unsigned long >> > gfn, unsigned int page_count) >> > +static

Re: [Xen-devel] [PATCH v4 6/6] hwmon: use smp_call_on_cpu() for dell-smm i8k

On Monday 09 May 2016 16:37:01 Juergen Gross wrote: > On 21/04/16 15:27, Pali Rohár wrote: > > On Thursday 21 April 2016 15:12:52 Juergen Gross wrote: > >> On 21/04/16 12:57, Pali Rohár wrote: > >>> On Tuesday 05 April 2016 21:31:52 Pali Rohár wrote: > On Tuesday 05 April 2016 16:54:14

Re: [Xen-devel] [PATCH v4 10/10] vt-d: propagate error up to ME phantom function mapping and unmapping

>>> On 12.05.16 at 07:16, wrote: > Taken together, there are 3 call trees to me_wifi_quirk(): > > 1). > ...--me_wifi_quirk()--domain_context_mapping_one()--domain_context_mapping()--se > tup_hwdom_device() > > There is no use in calling this function if

[Xen-devel] [distros-debian-wheezy test] 44409: trouble: blocked/broken

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

Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7

On Tue, May 10, 2016 at 10:46 AM, George Dunlap wrote: > On 10/05/16 03:18, Dario Faggioli wrote: >> On Mon, 2016-05-09 at 17:55 +0100, Lars Kurth wrote: Hard affinity tests shouldn't be too difficult to add in. >>> >>> That would be great >>> >> George, if you are

Re: [Xen-devel] [PATCH v4 01/10] vt-d: fix the IOMMU flush issue

On May 10, 2016 12:10 AM, Jan Beulich wrote: > >>> On 06.05.16 at 10:54, wrote: > > -static void intel_iommu_iotlb_flush(struct domain *d, unsigned long > > gfn, unsigned int page_count) > > +static void iommu_flush_iotlb_page(struct domain *d, unsigned long

Re: [Xen-devel] [libvirt] [PATCH 1/3] libxl: switch to using libxl_domain_create_restore from v4.4 API

On Wed, May 11, Jim Fehlig wrote: > https://www.redhat.com/archives/libvir-list/2016-May/msg00686.html Perhaps configure.ac should be changed to reject libxl upfront. It looks like the assignment of LIBXL_CFLAGS should be moved up, so that AC_CHECK_LIB gets the -DLIBXL_API_VERSION as well. I

[Xen-devel] [PATCH] xen/arm: mm: fix nr_second calculation in setup_frametable_mappings

To ARM64, "frametable_size >> SECOND_SHIFT" means the number of second level entries, not the number of second level pages. "DIV_ROUND_UP(frametable_size >> SECOND_SHIFT, LPAE_ENTRIES)" is the correct way to calculate the second level pages needed for frametable mapping. Signed-off-by: Peng Fan