[Xen-devel] [PATCH v4 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 v4 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 v4 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 v4 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] [PATCH v7 00/11] grub-xen: support booting huge pv-domains

Gentle ping... On 03/03/16 10:38, Juergen Gross wrote: > The Xen hypervisor supports starting a dom0 with large memory (up to > the TB range) by not including the initrd and p2m list in the initial > kernel mapping. Especially the p2m list can grow larger than the > available virtual space in the

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

On May 11, 2016 5:07 PM, Jan Beulich wrote: > >>> On 11.05.16 at 10:35, wrote: > > On May 10, 2016 5:29 PM, Jan Beulich wrote: > >> >>> On 06.05.16 at 10:54, wrote: > >> > @@ -1430,7 +1430,12 @@ int

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

Hi Boris, On 05/10/2016 02:11 PM, Boris Ostrovsky wrote: > On 05/10/2016 12:11 PM, Kevin Moraga wrote: > Can you boot your system bare-metal and post output of 'biosdecode' command? > > -boris Sure, it's attached. -- Sincerely, Kevin Moraga PGP: F258EDCB Fingerprint: 3915 A5A9 959C D18F 0A89

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

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

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

On 2016/5/12 7:24, Matt Fleming wrote: > On Wed, 11 May, at 09:35:47PM, Shannon Zhao wrote: >>> > > >>> > > Also, why do you need to setup efi.runtime_version here? Isn't that >>> > > done inside uefi_init()? >>> > > >> > I don't see any codes which setup efi.runtime_version in uefi_init(). >

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

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

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

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. Also no need to use write_pte when map BOOT_RELOC_VIRT_START in xen_second, because CPU0 is using boot page tables now. Signed-off-by: Peng Fan

[Xen-devel] [PATCH V2 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 --- V2:

[Xen-devel] [qemu-upstream-4.4-testing test] 94023: regressions - FAIL

flight 94023 qemu-upstream-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94023/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pv 17 guest-localmigrate/x10fail REGR. vs. 83041 Tests

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

Hi Dushyant, On Tue, Mar 8, 2016 at 3:23 AM, Dushyant K Behl wrote: > > Hi All, > > I'm working on a research project with IBM, and I want to run Xen on Nvidia > Tegra Jetson-tk1 board. > I looked at a post on this mailing list >

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

On 05/11/2016 12:01 AM, Olaf Hering wrote: > On Mon, May 02, Jim Fehlig wrote: > >> In LIBXL_API_VERSION 0x040400, the libxl_domain_create_restore API >> gained a parameter for specifying restore parameters. Switch to >> using version 0x040400, which will be useful in a subsequent commit >> to

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

On Wed, 11 May, at 09:35:47PM, Shannon Zhao wrote: > > > > Also, why do you need to setup efi.runtime_version here? Isn't that > > done inside uefi_init()? > > > I don't see any codes which setup efi.runtime_version in uefi_init(). Look in the EFI tree,

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

flight 94010 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/94010/ 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] [xen-unstable-smoke test] 94043: tolerable all pass - PUSHED

flight 94043 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/94043/ 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] [ovmf bisection] complete test-amd64-i386-xl-qemuu-ovmf-amd64

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemuu-ovmf-amd64 testid debian-hvm-install Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf https://github.com/tianocore/edk2.git Tree: qemu

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

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

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

flight 94018 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/94018/ 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

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

flight 94019 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94019/ 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

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

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 don't understand the "to minimize code changes" part.

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

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 only, and not for >>production use. >> >> +config

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

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 >> +bool "Crash Debugging Support" >> +depends on X86 >> +

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

flight 94001 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94001/ 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] xc_altp2m_set_vcpu_enable_notify fail

Hi Fangtuo, #VE can be setup to be delivered to any dom that is a HVM. Ravi From: Big Strong [mailto:fangtu...@gmail.com] Sent: Wednesday, May 11, 2016 8:38 AM To: Wei Liu Cc: Tamas K Lengyel ; Sahita, Ravi ; Xen-devel

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

On Wed, May 11, 2016 at 04:33:34PM +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. > > This patch adds the necessary code

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

On Wed, May 11, 2016 at 04:33:35PM +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

[Xen-devel] [PATCH net-next v2 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] [PATCH net-next v3 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 v2 4/4] xen-netback: use hash value from 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 use the value in a hash extra info fragment passed from the guest frontend in a transmit-side (i.e.

[Xen-devel] [PATCH net-next v2 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 v3 4/4] xen-netback: use hash value from 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 use the value in a hash extra info fragment passed from the guest frontend in a transmit-side (i.e.

[Xen-devel] [PATCH net-next v3 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

Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

Is that a bug or does #ve info page can only exist on dom0? If this is true, why would there be a is_hvm_domain check which will stop the execution of xc_altp2m_vcpu_enable_notify? 2016-05-11 15:56 GMT+08:00 Big Strong : > From what I analyzed, can I draw a concolusion that

[Xen-devel] [PATCH net-next v3 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 v2 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 v2 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 v3 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] [xen-4.6-testing test] 94000: regressions - FAIL

flight 94000 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94000/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 7 host-ping-check-xen fail REGR. vs. 93932 Regressions

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

> -Original Message- > From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: 11 May 2016 16:16 > To: xen-de...@lists.xenproject.org; net...@vger.kernel.org > Cc: Paul Durrant; Wei Liu > Subject: [PATCH net-next v2 2/4] xen-netback: add control protocol > implementation > > My recent

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

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 with corresponding non-atomic versions since schedule.c already has spin_locks in place.

Re: [Xen-devel] [PATCH] xen: remove incorrect forward declaration

On 05/11/2016 03:05 PM, Juergen Gross wrote: On 11/05/16 15:07, Arnd Bergmann wrote: A bugfix patch for the xen balloon driver introduced a forward declaration for a static function that is conditionally compiled, causing a warning if only the declaration but not the definition are there:

[Xen-devel] Please reconsider bug 26

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 https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1572446 (a trailing domu.cfg~ backup file will be

Re: [Xen-devel] [PATCH for-4.7 2/2] tools/xendomains: Create lockfile on start unconditionally

On Wed, May 11, George Dunlap wrote: > At the moment, the xendomains init script will only create a lockfile > if when started, it actually does something -- either tries to restore > a previously saved domain as a result of XENDOMAINS_RESTORE, or tries > to create a domain as a result of

Re: [Xen-devel] [PATCH for-4.7 1/2] hotplug: Fix xendomains lock path for RHEL-based systems

On Wed, May 11, George Dunlap wrote: > Commit c996572 changed the LOCKFILE path from a check between two > hardcoded paths (/var/lock/subsys/ or /var/lock) to using the > XEN_LOCK_DIR variable designated at configure time. Since > XEN_LOCK_DIR doesn't (and shouldn't) have the 'subsys' postfix,

Re: [Xen-devel] [PATCH] xsplice: Unmask (aka reinstall NMI handler) if we need to abort.

On 11/05/16 14:59, Konrad Rzeszutek Wilk wrote: > If we have to abort in xsplice_spin() we end following > the goto abort. But unfortunataly we neglected to unmask. > This patch fixes that. > > Reported-by: Martin Pohlack > Signed-off-by: Konrad Rzeszutek Wilk

Re: [Xen-devel] [PATCH for-4.7 2/2] tools/xendomains: Create lockfile on start unconditionally

On Wed, May 11, 2016 at 12:14:45PM +0100, George Dunlap wrote: > At the moment, the xendomains init script will only create a lockfile > if when started, it actually does something -- either tries to restore > a previously saved domain as a result of XENDOMAINS_RESTORE, or tries > to create a

Re: [Xen-devel] [PATCH for-4.7 2/2] tools/xendomains: Create lockfile on start unconditionally

On Wed, May 11, 2016 at 12:19:45PM +0100, George Dunlap wrote: > On 11/05/16 12:14, George Dunlap wrote: > > At the moment, the xendomains init script will only create a lockfile > > if when started, it actually does something -- either tries to restore > > a previously saved domain as a result of

Re: [Xen-devel] [PATCH for-4.7 1/2] hotplug: Fix xendomains lock path for RHEL-based systems

On Wed, May 11, 2016 at 12:14:44PM +0100, George Dunlap wrote: > Commit c996572 changed the LOCKFILE path from a check between two > hardcoded paths (/var/lock/subsys/ or /var/lock) to using the > XEN_LOCK_DIR variable designated at configure time. Since > XEN_LOCK_DIR doesn't (and shouldn't)

Re: [Xen-devel] [PATCH] xen: remove incorrect forward declaration

On 11/05/16 15:07, Arnd Bergmann wrote: > A bugfix patch for the xen balloon driver introduced a forward > declaration for a static function that is conditionally compiled, > causing a warning if only the declaration but not the definition > are there: > > drivers/xen/balloon.c:154:13: error:

Re: [Xen-devel] [PATCH] xsplice: Unmask (aka reinstall NMI handler) if we need to abort.

On Wed, May 11, 2016 at 09:59:08AM -0400, Konrad Rzeszutek Wilk wrote: > If we have to abort in xsplice_spin() we end following > the goto abort. But unfortunataly we neglected to unmask. > This patch fixes that. > > Reported-by: Martin Pohlack > Signed-off-by: Konrad

Re: [Xen-devel] [REVERT] blktap2: Use RING_COPY_REQUEST

On Wed, May 11, 2016 at 02:44:19PM +0100, Wei Liu wrote: > On Wed, May 11, 2016 at 04:00:39AM -0600, Jan Beulich wrote: > > >>> On 02.05.16 at 12:16, wrote: > > > On Fri, Apr 22, 2016 at 02:44:25AM -0600, Jan Beulich wrote: > > >> Short of getting any feedback on the previous

[Xen-devel] [PATCH] xsplice: Unmask (aka reinstall NMI handler) if we need to abort.

If we have to abort in xsplice_spin() we end following the goto abort. But unfortunataly we neglected to unmask. This patch fixes that. Reported-by: Martin Pohlack Signed-off-by: Konrad Rzeszutek Wilk --- Cc: jbeul...@suse.com Cc:

Re: [Xen-devel] [PATCH v9 12/27] xsplice: Implement support for applying/reverting/replacing patches.

On Wed, May 11, 2016 at 11:51:53AM +0200, Martin Pohlack wrote: > On 27.04.2016 05:39, Konrad Rzeszutek Wilk wrote: > [...] > > +/* "Mask" NMIs. */ > > +arch_xsplice_mask(); > > You mask here ... > > > +barrier(); /* MUST do it after get_cpu_maps. */ > > +cpus =

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

On 06/05/16 13:41, Juergen Gross 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 blkif_request_discard

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

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

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

During Xen boot I am seeing the panic in the subject line from .../xen/drivers/passthrough/vgt/qinval.c From the Fault Status Register (= 0x40 (ITE)). I am seeing a hardware timeout on the invalidate Disabling queued invalidation is not an option. I need to find out why the operation is

Re: [Xen-devel] [REVERT] blktap2: Use RING_COPY_REQUEST

On Wed, May 11, 2016 at 04:00:39AM -0600, Jan Beulich wrote: > >>> On 02.05.16 at 12:16, wrote: > > On Fri, Apr 22, 2016 at 02:44:25AM -0600, Jan Beulich wrote: > >> Short of getting any feedback on the previous discussion item > >>

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

On 2016年05月11日 20:27, Matt Fleming wrote: > On Fri, 06 May, at 04:32:06PM, Shannon Zhao wrote: >> > From: Shannon Zhao >> > >> > Add a new function to parse DT parameters for Xen specific UEFI just >> > like the way for normal UEFI. Then it could reuse the existing

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

On 11/05/16 14:48, David Vrabel wrote: > On 11/05/16 13:21, Jan Beulich wrote: > On 11.05.16 at 12:16, wrote: >>> On 11/05/16 08:00, Juergen Gross wrote: Adding David as he removed _PAGE_IOMAP in kernel 3.18. >>> >>> Why don't we get the RW bits correct when

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

>>> On 11.05.16 at 14:48, wrote: > On 11/05/16 13:21, Jan Beulich wrote: > On 11.05.16 at 12:16, wrote: >>> On 11/05/16 08:00, Juergen Gross wrote: Adding David as he removed _PAGE_IOMAP in kernel 3.18. >>> >>> Why don't we get the RW

[Xen-devel] [PATCH] xen: remove incorrect forward declaration

A bugfix patch for the xen balloon driver introduced a forward declaration for a static function that is conditionally compiled, causing a warning if only the declaration but not the definition are there: drivers/xen/balloon.c:154:13: error: 'release_memory_resource' declared 'static' but never

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

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. So this leaves staging-4.4. Olaf

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

flight 94028 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/94028/ 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] [xen-4.5-testing test] 93989: tolerable FAIL - PUSHED

flight 93989 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/93989/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-libvirt 14 guest-saverestore fail in 93928 pass in 93989 test-armhf-armhf-xl 15

[Xen-devel] [PATCH] Xen: don't warn about 2-byte wchar_t in efi

The XEN UEFI code has become available on the ARM architecture recently, but now causes a link-time warning: ld: warning: drivers/xen/efi.o uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail This seems harmless, because the efi code only

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

On 11/05/16 13:21, Jan Beulich wrote: On 11.05.16 at 12:16, wrote: >> On 11/05/16 08:00, Juergen Gross wrote: >>> Adding David as he removed _PAGE_IOMAP in kernel 3.18. >> >> Why don't we get the RW bits correct when making the pteval when we >> already have the pfn,

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

> -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 4.7 fails in ioreq > server > > On 11/05/16 13:18, Olaf Hering wrote:

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

On Wed, May 11, Andrew Cooper wrote: > On 11/05/16 13:18, Olaf Hering wrote: > > Migrating a HVM guest from staging-4.4 to staging fails: > > > > # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log > > char device redirected to /dev/pts/3 (label serial0) > > xen: ioreq server create:

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

On Fri, 06 May, at 09:52:42AM, Mathieu Poirier wrote: > > +static int __init efi_remap_init(void) > > +{ > > + u64 mapsize; > > + > > + pr_info("Remapping and enabling EFI services.\n"); > > + > > + mapsize = memmap.map_end - memmap.map; > > + memmap.map = (__force void

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

On Fri, 06 May, at 04:32:06PM, Shannon Zhao wrote: > From: Shannon Zhao > > Add a new function to parse DT parameters for Xen specific UEFI just > like the way for normal UEFI. Then it could reuse the existing codes. > > If Xen supports EFI, initialize runtime services.

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

On 11/05/16 13:18, Olaf Hering wrote: > Migrating a HVM guest from staging-4.4 to staging fails: > > # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log > char device redirected to /dev/pts/3 (label serial0) > xen: ioreq server create: Cannot allocate memory > qemu-system-x86_64: xen

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

>>> On 11.05.16 at 12:16, wrote: > On 11/05/16 08:00, Juergen Gross wrote: >> Adding David as he removed _PAGE_IOMAP in kernel 3.18. > > Why don't we get the RW bits correct when making the pteval when we > already have the pfn, instead trying to fix it up afterwards.

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

Migrating a HVM guest from staging-4.4 to staging fails: # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log char device redirected to /dev/pts/3 (label serial0) xen: ioreq server create: Cannot allocate memory qemu-system-x86_64: xen hardware virtual machine initialisation failed

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

>>> On 11.05.16 at 12:10, wrote: > On 11/05/16 12:03, Jan Beulich wrote: > On 11.05.16 at 11:57, wrote: >>> On 11/05/16 09:15, Jan Beulich wrote: >>> On 11.05.16 at 09:00, wrote: > Having a Xen specific pte flag seems to be much

Re: [Xen-devel] [PATCH for-4.7 2/2] tools/xendomains: Create lockfile on start unconditionally

On 11/05/16 12:14, George Dunlap wrote: > At the moment, the xendomains init script will only create a lockfile > if when started, it actually does something -- either tries to restore > a previously saved domain as a result of XENDOMAINS_RESTORE, or tries > to create a domain as a result of

[Xen-devel] [PATCH for-4.7 2/2] tools/xendomains: Create lockfile on start unconditionally

At the moment, the xendomains init script will only create a lockfile if when started, it actually does something -- either tries to restore a previously saved domain as a result of XENDOMAINS_RESTORE, or tries to create a domain as a result of XENDOMAINS_AUTO. RedHat-based SYSV init systems try

[Xen-devel] [PATCH for-4.7 1/2] hotplug: Fix xendomains lock path for RHEL-based systems

Commit c996572 changed the LOCKFILE path from a check between two hardcoded paths (/var/lock/subsys/ or /var/lock) to using the XEN_LOCK_DIR variable designated at configure time. Since XEN_LOCK_DIR doesn't (and shouldn't) have the 'subsys' postfix, this effectively moves all the lock files by

[Xen-devel] Announcing Xen Project 4.7 RC and Test Day Schedule

Dear Community members, Yesterday, we created Xen 4.7 RC2 and will release a new release candidate every Wednesday, until we declare a release candidate as the final candidate and cut the Xen 4.7 release. We will also hold a Test Day [1] every Friday for the release candidate that was released

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

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

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

On Wed, May 11, 2016 at 10:36:28AM +0200, Juergen Gross wrote: > On 10/05/16 18:21, Anthony PERARD wrote: > > On Fri, May 06, 2016 at 11:42:45AM +0200, Juergen Gross wrote: > >> -static int xen_config_dev_mkdir(char *dev, int p) > >> -{ > >> -struct xs_permissions perms[2] = {{ > >> -

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

On Fri, May 06, 2016 at 11:42:46AM +0200, Juergen Gross wrote: > 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

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

flight 94022 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/94022/ 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] crash on boot with 4.6.1 on fedora 24

On 11/05/16 08:00, Juergen Gross wrote: > On 11/05/16 08:35, Jan Beulich wrote: > On 11.05.16 at 07:49, wrote: >>> On 10/05/16 18:35, Boris Ostrovsky wrote: On 05/10/2016 11:43 AM, Juergen Gross wrote: > On 10/05/16 17:35, Jan Beulich wrote: > On 10.05.16 at

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

On 11/05/16 12:03, Jan Beulich wrote: On 11.05.16 at 11:57, wrote: >> On 11/05/16 09:15, Jan Beulich wrote: >> On 11.05.16 at 09:00, wrote: Having a Xen specific pte flag seems to be much more intrusive than having an early boot page fault

Re: [Xen-devel] [PATCH] xen/arm: mm: optimize setup_pagetables

On Wed, May 11, 2016 at 11:03:06AM +0100, Julien Grall wrote: > > >On 11/05/2016 10:57, Peng Fan wrote: >>Hi Julien, > >Hi Peng, > >>On Wed, May 11, 2016 at 10:31:49AM +0100, Julien Grall wrote: >>> >>>[...] >>> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index 94ea054..bebd82f

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

>>> On 11.05.16 at 11:57, wrote: > On 11/05/16 09:15, Jan Beulich wrote: > On 11.05.16 at 09:00, wrote: >>> Having a Xen specific pte flag seems to be much more intrusive than >>> having an early boot page fault handler consisting of just one line >>> being

Re: [Xen-devel] [PATCH] xen/arm: mm: optimize setup_pagetables

On 11/05/2016 10:57, Peng Fan wrote: Hi Julien, Hi Peng, On Wed, May 11, 2016 at 10:31:49AM +0100, Julien Grall wrote: [...] diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index 94ea054..bebd82f 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -443,12 +443,6 @@ void __init

Re: [Xen-devel] [REVERT] blktap2: Use RING_COPY_REQUEST

>>> On 02.05.16 at 12:16, wrote: > On Fri, Apr 22, 2016 at 02:44:25AM -0600, Jan Beulich wrote: >> Short of getting any feedback on the previous discussion item >> http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg00571.html >> here's a formal revert request:

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

On 11/05/16 09:15, Jan Beulich wrote: On 11.05.16 at 09:00, wrote: >> Having a Xen specific pte flag seems to be much more intrusive than >> having an early boot page fault handler consisting of just one line >> being capable to mimic the default handler in just one aspect

Re: [Xen-devel] [PATCH] xen/arm: mm: optimize setup_pagetables

Hi Julien, On Wed, May 11, 2016 at 10:31:49AM +0100, Julien Grall wrote: >Hi Peng, > >I would rename the title: "xen/arm: mm: remove unnecessary tlb flush in >setup_pagetables". Thanks. Will fix in V2. > >On 11/05/2016 08:59, Peng Fan wrote: >>Before relocating xen to high address, need to

Re: [Xen-devel] [PATCH v9 12/27] xsplice: Implement support for applying/reverting/replacing patches.

On 27.04.2016 05:39, Konrad Rzeszutek Wilk wrote: [...] > +/* "Mask" NMIs. */ > +arch_xsplice_mask(); You mask here ... > +barrier(); /* MUST do it after get_cpu_maps. */ > +cpus = num_online_cpus() - 1; > + > +if ( cpus ) > +{ > +

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

>>> 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 don't understand the "to minimize code changes" part. > @@ -12,18 +10,15 @@ lto ?= n > >

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

>>> 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 > + bool "Crash Debugging Support" > + depends on X86 > + ---help--- > + If you want to be able to

[Xen-devel] [qemu-upstream-unstable baseline-only test] 44403: regressions - trouble: blocked/broken/fail/pass

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

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

>>> 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 only, and not for > production use. > > +config VERBOSE_DEBUG > + bool "Verbose debug

Re: [Xen-devel] [PATCH] xen/arm: mm: optimize setup_pagetables

Hi Peng, I would rename the title: "xen/arm: mm: remove unnecessary tlb flush in setup_pagetables". On 11/05/2016 08:59, Peng Fan wrote: Before relocating xen to high address, need to build the mapping BOOT_RELOC_VIRT_START to xen_paddr into boot_pgtable and xen_pgtable. In

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

>>> On 11.05.16 at 10:35, wrote: > On May 10, 2016 5:29 PM, Jan Beulich wrote: >> >>> On 06.05.16 at 10:54, wrote: >> > @@ -1430,7 +1430,12 @@ int domain_context_mapping_one( >> > unmap_vtd_domain_page(context_entries); >> > >> >

  1   2   >