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

flight 93717 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/93717/ 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 test] 93638: tolerable FAIL - PUSHED

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

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

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

Re: [Xen-devel] [PATCH for 4.7 4/4] xen: adopt .deinit_pdata and improve timer handling

On Wed, 2016-05-04 at 11:53 -0400, Meng Xu wrote: > On Wed, May 4, 2016 at 11:51 AM, George Dunlap com> wrote: > > On 03/05/16 22:46, Dario Faggioli wrote: > > > This also made it possible to improve the replenishment > > > timer handling logic, such that now the timer is

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

flight 93633 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/93633/ 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 test] 93612: regressions - FAIL

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

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

flight 93616 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/93616/ 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] 93623: tolerable all pass - PUSHED

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

The following images should be placed in the osstest images folder: ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/10.3-RELEASE/amd64/Latest/FreeBSD-10.3-RELEASE-amd64.raw.xz ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/10.3-RELEASE/i386/Latest/FreeBSD-10.3-RELEASE-i386.raw.xz

[Xen-devel] [Hackathon 2016] Scheduling session minutes

Hi everyone, I still owe this list the minutes of the session we had at the hackathon about scheduling. It was a round table with status updates being given on ongoing activities, as well as a few ideas for future work/improvements being tossed, so nothing too structured, but here we go. I did

Re: [Xen-devel] [PATCH v2 for-4.7 5/6] xen/xsplice: add ELFOSABI_FREEBSD as a supported OSABI for payloads

On Fri, May 06, 2016 at 01:48:08PM +0100, Ross Lagerwall wrote: > On 05/03/2016 11:55 AM, Roger Pau Monne wrote: > >The calling convention used by the FreeBSD ELF OSABI is exactly the same as > >the the one defined by System V, so payloads with a FreeBSD OSABI should be > >accepted by the xsplice

[Xen-devel] [PATCH v7 08/19] xen_disk: Switch to byte-based aio block access

Sector-based blk_aio_readv() and blk_aio_writev() should die; switch to byte-based blk_aio_preadv() and blk_aio_pwritev() instead. Signed-off-by: Eric Blake --- hw/block/xen_disk.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git

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

On 6 May 2016 at 02:32, 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

Re: [Xen-devel] cc-option in Config.mk and -Og

Wei Liu writes ("cc-option in Config.mk and -Og"): > $(call cc-option-add,CFLAGS,CC,-Og) > > However the output of -O option is different from what cc-option > expects: I think cc-option is only suitable for use with warning options. Sorry for leaving this bear trap. > Any thought on how to

[Xen-devel] cc-option in Config.mk and -Og

Hi, I discover an issue with cc-option in Config.mk. # cc-option: Check if compiler supports first option, else fall back to second. # This is complicated by the fact that unrecognised -Wno-* options: # (a) are

[Xen-devel] [PATCH v1 4/7] page-alloc: Remove dependency on __LINE__ for release builds

When using xsplice, use of __LINE__ can generate spurious changes in functions due to embedded line numbers. For release builds, remove the use of these line numbers in BOOT_BUG_ON() and print the current text address instead. Signed-off-by: Ross Lagerwall ---

[Xen-devel] [PATCH v1 6/7] acpi: Remove dependency on __LINE__ for release builds

When using xsplice, use of __LINE__ can generate spurious changes in functions due to embedded line numbers. For release builds, remove the use of these line numbers in the ACPI code and print the current text address instead. Signed-off-by: Ross Lagerwall ---

[Xen-devel] [PATCH v1 1/7] lib: Add a generic implementation of current_text_addr()

Remove the unused x86 implementation. Signed-off-by: Ross Lagerwall --- xen/common/lib.c| 12 xen/include/asm-x86/processor.h | 10 -- xen/include/xen/lib.h | 2 ++ 3 files changed, 14 insertions(+), 10 deletions(-)

[Xen-devel] [PATCH v1 5/7] iommu: Remove dependency on __LINE__ for release builds

When using xsplice, use of __LINE__ can generate spurious changes in functions due to embedded line numbers. For release builds, remove the use of these line numbers in IOMMU_WAIT_OP() and print the current text address instead. Signed-off-by: Ross Lagerwall ---

[Xen-devel] [PATCH v1 7/7] Rename sections for compatibility with -ffunction-sections -fdata-sections

When building with -ffunction-sections -fdata-sections, it will generate section names like .text.show_handlers and .data.payload_list. These sections are in the same namespace as the special sections that Xen uses, such as .text.kexec and .data.schedulers. To prevent conflicts, prefix Xen's

[Xen-devel] [PATCH v1 3/7] mm: Use statically defined locking order

Instead of using a locking order based on line numbers which doesn't play nicely with xSplice, statically define the locking order. Signed-off-by: Ross Lagerwall --- xen/arch/x86/mm/mm-locks.h | 29 - 1 file changed, 20 insertions(+), 9

[Xen-devel] [PATCH v1 2/7] sched: Remove dependency on __LINE__ for release builds

When using xsplice, use of __LINE__ can generate spurious changes in functions due to embedded line numbers. For release builds, remove the use of these line numbers in domain_crash*() and print the current text address instead. Signed-off-by: Ross Lagerwall ---

[Xen-devel] [PATCH v1 0/7] Make building xSplice patches easier

Here is a set of changes to make building xSplice patches easier. Tested to boot on x86. Compile-tested on arm. This is probably too late to make it into 4.7, but hey, if someone wants to put it in I've CC'd Wei. Ross Lagerwall (7): lib: Add a generic implementation of current_text_addr()

Re: [Xen-devel] [PATCH] IOMMU: don't BUG() on exotic hardware

On Fri, May 6, 2016 at 4:31 PM, Wei Liu wrote: > On Fri, May 06, 2016 at 08:24:28AM -0600, Jan Beulich wrote: >> On x86, iommu_get_ops() BUG()s when running on non-Intel, non-AMD >> hardware. While, with our current code, that's a correct prerequisite >> assumption for IOMMU

Re: [Xen-devel] Debugging Xen early boot

On Fri, May 06, 2016 at 01:41:38PM +, Zytaruk, Kelly wrote: > > > > -Original Message- > > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan > > Beulich > > Sent: Friday, May 06, 2016 8:54 AM > > To: Zytaruk, Kelly > > Cc: xen-devel@lists.xen.org > > Subject:

Re: [Xen-devel] [PATCH 2/3] xtf: avoid shifting a negative value

On 06/05/16 15:57, Andrew Cooper wrote: > On 06/05/16 15:25, Roger Pau Monne wrote: >> Because it's undefined behaviour. >> >> Signed-off-by: Roger Pau Monné >> --- >> Cc: Andrew Cooper >> --- >> include/arch/x86/processor.h | 2 +- >> 1 file

Re: [Xen-devel] [PATCH 2/3] xtf: avoid shifting a negative value

On 06/05/16 15:25, Roger Pau Monne wrote: > Because it's undefined behaviour. > > Signed-off-by: Roger Pau Monné > --- > Cc: Andrew Cooper > --- > include/arch/x86/processor.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [Xen-devel] [PATCH for-4.7 0/6] Workaround gcc -Wmaybe-uninitialised false positive reports

On Fri, May 06, 2016 at 08:37:31AM -0500, Doug Goldstein wrote: > On 4/29/16 10:11 AM, Wei Liu wrote: > > On my Debian Jessie build box gcc complains about various maybe > > uninitialised > > variables when -g is in use. In fact gcc -Wmaybe-uninitialized is not very > > reliable according to gcc

Re: [Xen-devel] [PATCH 0/3] XTF: small fixes

On 06/05/16 15:25, Roger Pau Monne wrote: > Hello, > > This is a series of very small fixes for XTF, the first two are code fixes, > while the last one is a build system fix. > > Thanks, Roger. 1 and 3 look fine - I will take them straight as-is. 2 is slightly more problematic - comment on that

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

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 gets rid of the vmx_introspection_force_enabled_msrs[] special case.

Re: [Xen-devel] [PATCH] IOMMU: don't BUG() on exotic hardware

On Fri, May 06, 2016 at 08:24:28AM -0600, Jan Beulich wrote: > On x86, iommu_get_ops() BUG()s when running on non-Intel, non-AMD > hardware. While, with our current code, that's a correct prerequisite > assumption for IOMMU presence, this is wrong on systems without IOMMU. > Hence iommu_enabled

Re: [Xen-devel] [PATCH] XSA-77: widen scope again

On Fri, Apr 29, 2016 at 03:35:51AM -0600, Jan Beulich wrote: > As discussed on the hackathon, avoid us having to issue security > advisories for issues affecting only heavily disaggregated tool stack > setups, which no-one appears to use (or else they should step up to get > things into shape). >

[Xen-devel] [PATCH 2/3] xtf: avoid shifting a negative value

Because it's undefined behaviour. Signed-off-by: Roger Pau Monné --- Cc: Andrew Cooper --- include/arch/x86/processor.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/arch/x86/processor.h

[Xen-devel] [PATCH 1/3] xtf: don't re-define __noinline

On FreeBSD __noinline is already defined in cdefs.h Signed-off-by: Roger Pau Monné --- Cc: Andrew Cooper --- include/xtf/compiler.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/xtf/compiler.h b/include/xtf/compiler.h index

[Xen-devel] [PATCH 3/3] xtf: fix usage of "-executable" with find

"-executable" is a GNU only extension to find. Instead replace it with a POSIX compatible one. Signed-off-by: Roger Pau Monné --- Cc: Andrew Cooper --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile

[Xen-devel] [PATCH 0/3] XTF: small fixes

Hello, This is a series of very small fixes for XTF, the first two are code fixes, while the last one is a build system fix. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] IOMMU: don't BUG() on exotic hardware

On x86, iommu_get_ops() BUG()s when running on non-Intel, non-AMD hardware. While, with our current code, that's a correct prerequisite assumption for IOMMU presence, this is wrong on systems without IOMMU. Hence iommu_enabled (and alike) checks should be done prior to calling that function, not

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

flight 93611 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/93611/ 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 for 4.7 1/4] xen: sched: avoid spuriously re-enabling IRQs in csched2_switch_sched()

On Fri, May 06, 2016 at 03:21:40PM +0200, Dario Faggioli wrote: > On Wed, 2016-05-04 at 18:34 +0100, George Dunlap wrote: > > On 04/05/16 18:21, Dario Faggioli wrote: > > >  > > > After all, I'm fine with an ASSERT() too, but then I think we > > > should > > > add one to the same effect to

Re: [Xen-devel] Debugging Xen early boot

> -Original Message- > From: David Vrabel [mailto:david.vra...@citrix.com] > Sent: Friday, May 06, 2016 9:04 AM > To: Zytaruk, Kelly; Konrad Rzeszutek Wilk > Cc: xen-devel@lists.xen.org > Subject: Re: [Xen-devel] Debugging Xen early boot > > On 06/05/16 13:31, Zytaruk, Kelly wrote: > >

Re: [Xen-devel] Debugging Xen early boot

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan > Beulich > Sent: Friday, May 06, 2016 8:54 AM > To: Zytaruk, Kelly > Cc: xen-devel@lists.xen.org > Subject: Re: [Xen-devel] Debugging Xen early boot > > >>> On 06.05.16 at 14:31,

Re: [Xen-devel] [PATCH v10 0/3] Re: VT-d Device-TLB flush issue

On May 06, 2016 9:36 PM, Jan Beulich wrote: > >>> On 06.05.16 at 14:21, wrote: > > If i didn't miss something, there is still no comment for this patch set. > > I think this patch set is close to being ready. I hope this patch set > > is still in your

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

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

Re: [Xen-devel] [PATCH for-4.7 0/6] Workaround gcc -Wmaybe-uninitialised false positive reports

On 4/29/16 10:11 AM, Wei Liu wrote: > On my Debian Jessie build box gcc complains about various maybe uninitialised > variables when -g is in use. In fact gcc -Wmaybe-uninitialized is not very > reliable according to gcc manpage, various search results and answer from > someone on freenode #gcc

[Xen-devel] [PATCH v10 0/3] Re: VT-d Device-TLB flush issue

>>> On 06.05.16 at 14:21, wrote: > If i didn't miss something, there is still no comment for this patch set. > I think this patch set is close to being ready. I hope this patch set is > still in your waiting-review list, but not missed.:) As said before, with this series

Re: [Xen-devel] [PATCH for 4.7 1/4] xen: sched: avoid spuriously re-enabling IRQs in csched2_switch_sched()

On Wed, 2016-05-04 at 18:34 +0100, George Dunlap wrote: > On 04/05/16 18:21, Dario Faggioli wrote: > >  > > After all, I'm fine with an ASSERT() too, but then I think we > > should > > add one to the same effect to csched_switch_sched() too. > Well an ASSERT() is sort of like a comment, in that if

[Xen-devel] [xen-unstable baseline-only test] 44392: regressions - FAIL

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

Re: [Xen-devel] Debugging Xen early boot

On 06/05/16 13:31, Zytaruk, Kelly wrote: > > As for the other question I am still curious as to how to debug > early Xen. How was __start_xen written and tested, what sort of tools were > used to debug it and get it working right? What do I do in situations > where I absolutely can't get serial

Re: [Xen-devel] Debugging Xen early boot

>>> On 06.05.16 at 14:31, wrote: > As for the other question I am still curious as to how to debug early Xen. > How was __start_xen written and tested, what sort of tools were used to debug > it and get it working right? I don't know how it was done here, but having

Re: [Xen-devel] SMMU, Unhandled context fault

Hello Peng, On 03/05/16 14:58, Peng Fan wrote: On Tue, May 03, 2016 at 11:58:17AM +0100, Julien Grall wrote: On 29/04/16 15:28, Peng Fan wrote: Hi Julien, Hello Peng, On Thu, Apr 28, 2016 at 02:14:58PM +0100, Julien Grall wrote: Is there any big difference between XEN SMMU driver and

Re: [Xen-devel] [PATCH v2 for-4.7 5/6] xen/xsplice: add ELFOSABI_FREEBSD as a supported OSABI for payloads

On 05/03/2016 11:55 AM, Roger Pau Monne wrote: The calling convention used by the FreeBSD ELF OSABI is exactly the same as the the one defined by System V, so payloads with a FreeBSD OSABI should be accepted by the xsplice machinery. Signed-off-by: Roger Pau Monné --- Cc:

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

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

Konrad, immediate problem is solved although I don't know why. I tried putting the serial card into a different PCIe slot and it works properly. Must be something wrong with the slot. I will leave that as a problem for another day. As for the other question I am still curious as to how to

[Xen-devel] [PATCH v10 0/3] Re: VT-d Device-TLB flush issue

hi, If i didn't miss something, there is still no comment for this patch set. I think this patch set is close to being ready. I hope this patch set is still in your waiting-review list, but not missed.:) Thanks in advance!! Quan On 22 Apr 2016, at 18:38:49 +0800, Quan Xu

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

flight 93605 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/93605/ 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] potential problem with qdisk backend

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 while qemu treats them to be the same. Am I

Re: [Xen-devel] [PATCH for-4.7 0/6] Workaround gcc -Wmaybe-uninitialised false positive reports

On Fri, Apr 29, 2016 at 04:11:11PM +0100, Wei Liu wrote: > On my Debian Jessie build box gcc complains about various maybe uninitialised > variables when -g is in use. In fact gcc -Wmaybe-uninitialized is not very > reliable according to gcc manpage, various search results and answer from >

Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

On Wed, May 04, 2016 at 08:59:35PM +0800, Big Strong wrote: [...] > > > The code always stops at the xc_altp2m_set_vcpu_enable_notify, which is > used to assign the new page as #VE info page. As I can't debug the Xen > source code, I don't why xc_altp2m_set_vcpu_enable_notify always return -1.

Re: [Xen-devel] [PATCH for-4.7 1/2] init: drop GNU-isms for sleep command

Ack + release ack and queued both patches ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable test] 93587: tolerable FAIL

flight 93587 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/93587/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail in 93563 pass in 93587

Re: [Xen-devel] problem about using xl create to start a domU

On Fri, 6 May 2016, Shannon Zhao wrote: > On 2016/5/6 16:51, Julien Grall wrote: > > Hi Shannon, > > > > On 06/05/16 03:33, Shannon Zhao wrote: > >> Below is the output of xenstore-ls: > >> > >> root@genericarmv8:/home# xenstore-ls -f > >> /tool = "" > >> /tool/xenstored = "" > >> /local = "" >

Re: [Xen-devel] Some questions about Networking and storage.

>>> On 06.05.16 at 11:30, wrote: > Hello.I want to start my first VM via Xen and need your advice :1- How can I > setup a NIC for my VM? Is it Bridge?2- My computer have two partitions and I > want to dedicate second partition for my VMs, Must I create LVM or...? How > can

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

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

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

>>> On 06.05.16 at 10:50, wrote: > Changes since V7: > - Added Kevin Tian's ack. > - Moved memset()s from arch_monitor_init_domain() to >arch_monitor_cleanup_domain(), as suggested by Jan Beulich. > - Now using sizeof() instead of ARRAY_SIZE() in >

Re: [Xen-devel] problem about using xl create to start a domU

On 2016/5/6 16:51, Julien Grall wrote: > Hi Shannon, > > On 06/05/16 03:33, Shannon Zhao wrote: >> Below is the output of xenstore-ls: >> >> root@genericarmv8:/home# xenstore-ls -f >> /tool = "" >> /tool/xenstored = "" >> /local = "" >> /local/domain = "" >> /local/domain/0 = "" >>

Re: [Xen-devel] [PATCH for 4.7] pvusb: add missing definition to usbif.h

On Fri, May 06, 2016 at 01:56:36AM -0600, Jan Beulich wrote: > >>> On 06.05.16 at 09:49, wrote: > On 06.05.16 at 07:01, wrote: > >> On 05/05/16 11:22, Wei Liu wrote: > >>> On Thu, May 05, 2016 at 11:10:33AM +0200, Juergen Gross wrote: > On 05/05/16

Re: [Xen-devel] [PATCH for 4.7] pvusb: add missing definition to usbif.h

On Fri, May 06, 2016 at 07:01:12AM +0200, Juergen Gross wrote: > On 05/05/16 11:22, Wei Liu wrote: > > On Thu, May 05, 2016 at 11:10:33AM +0200, Juergen Gross wrote: > >> On 05/05/16 11:02, Wei Liu wrote: > >>> On Thu, May 05, 2016 at 08:36:45AM +0200, Juergen Gross wrote: > The pvusb request

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

flight 93589 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/93589/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt 14 guest-saverestore fail REGR. vs. 91479

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

On 6/05/2016 7:09 PM, Roger Pau Monné wrote: > On Thu, May 05, 2016 at 03:52:30PM +1000, 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 aware

[Xen-devel] [PATCH v3 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 v3 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 --- V3: multiple small changes as requested by Anthony Perard

[Xen-devel] [PATCH v3 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 v3 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] v2 - Add exclusive locking option to block-iscsi

On Thu, May 05, 2016 at 03:52:30PM +1000, 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 aware filesystems, this > > can lead to disk corruption and

[Xen-devel] [PATCH v4 07/10] IOMMU: propagate IOMMU Device-TLB flush error up to iommu_iotlb_flush{, _all} (leaf ones).

Propagate the IOMMU Device-TLB flush error up to the iommu_iotlb_flush{,_all}. This patch fixes the leaf ones. Signed-off-by: Quan Xu Acked-by: Kevin Tian CC: Stefano Stabellini CC: Julien Grall CC: Jan

[Xen-devel] [PATCH v4 03/10] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping

When IOMMU mapping is failed, we issue a best effort rollback, stopping IOMMU mapping, unmapping the previous IOMMU maps and then reporting the error up to the call trees. When rollback is not feasible (in early initialization phase or trade-off of complexity) for the hardware domain, we do things

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

The propagation value from IOMMU flush interfaces may be positive, which indicates callers need to flush cache, not one of faliures. when the propagation value is positive, this patch fixes this flush issue as follows: - call iommu_flush_write_buffer() to flush cache. - return zero.

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

Propagate the IOMMU Device-TLB flush error up to IOMMU suspending. Signed-off-by: Quan Xu CC: Jan Beulich CC: Liu Jinsong CC: Keir Fraser CC: Andrew Cooper CC: Suravee Suthikulpanit

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

Propagate the IOMMU Device-TLB flush error up to ME phantom function mapping and unmapping. Signed-off-by: Quan Xu CC: Jan Beulich CC: Kevin Tian CC: Feng Wu --- xen/drivers/passthrough/vtd/extern.h | 3 ++-

[Xen-devel] [PATCH v4 00/10] Check VT-d Device-TLB flush error

This patch set is a prereq patch set for Patch:'VT-d Device-TLB flush issue'. While IOMMU Device-TLB flush timed out, xen calls panic() at present. However the existing panic() is going to be eliminated, so we must propagate the IOMMU Device-TLB flush error up to the call trees. This patch set

[Xen-devel] [PATCH v4 04/10] vt-d: propagate IOMMU Device-TLB flush error up to IOMMU unmapping.

Propagate the IOMMU Device-TLB flush error up to IOMMU unmapping. Signed-off-by: Quan Xu Acked-by: Kevin Tian CC: Kevin Tian CC: Feng Wu CC: Jan Beulich ---

[Xen-devel] [PATCH v4 05/10] vt-d: propagate IOMMU Device-TLB flush error up to IOMMU mapping.

Propagate the IOMMU Device-TLB flush error up to IOMMU mapping. Signed-off-by: Quan Xu Acked-by: Kevin Tian CC: Kevin Tian CC: Feng Wu CC: Jan Beulich ---

[Xen-devel] [PATCH v4 08/10] vt-d/ept: propagate IOMMU Device-TLB flush error up to EPT update.

Propagate the IOMMU Device-TLB flush error up to the ept_set_entry(), when VT-d shares EPT page table. Signed-off-by: Quan Xu Acked-by: Kevin Tian CC: Jun Nakajima CC: Kevin Tian CC: George Dunlap

[Xen-devel] [PATCH v4 06/10] IOMMU/MMU: propagate IOMMU Device-TLB flush error up to iommu_iotlb_flush{, _all} (top level ones).

Propagate the IOMMU Device-TLB flush error up to the iommu_iotlb_flush{,_all}. This patch fixes the top level ones (this patch doesn't fix the leaf ones but the next patch does). Signed-off-by: Quan Xu CC: Stefano Stabellini CC: Julien Grall

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

Treat IOMMU mapping and unmapping failures as a fatal to the domain (with the exception of the hardware domain). If IOMMU mapping and unmapping failed, crash the domain (with the exception of the hardware domain) and propagate the error up to the call trees. Signed-off-by: Quan Xu

Re: [Xen-devel] [PATCH v2 for-4.7 3/6] tools/xsplice: fix mixing system errno values with Xen ones.

On Tue, May 03, 2016 at 09:37:01AM -0400, Konrad Rzeszutek Wilk wrote: > On Tue, May 03, 2016 at 02:29:20PM +0100, Wei Liu wrote: > > On Tue, May 03, 2016 at 09:27:23AM -0400, Konrad Rzeszutek Wilk wrote: > > > On Tue, May 03, 2016 at 12:55:07PM +0200, Roger Pau Monne wrote: > > > > Avoid using

Re: [Xen-devel] problem about using xl create to start a domU

Hi Shannon, On 06/05/16 03:33, Shannon Zhao wrote: Below is the output of xenstore-ls: root@genericarmv8:/home# xenstore-ls -f /tool = "" /tool/xenstored = "" /local = "" /local/domain = "" /local/domain/0 = "" /local/domain/0/domid = "0" /local/domain/0/name = "Domain-0" /vm = "" /libxl = ""

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

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 gets rid of the vmx_introspection_force_enabled_msrs[] special case.

Re: [Xen-devel] question about p2m_pod_demand_populate

hi Jan On 06.05.16 at 08:55, wrote: >> in p2m_pod_demand_populate >> i see： >> p2m_pod_demand_populate >>- pod_eager_reclaim >>- pod_eager_record >> >> if gfn is pod， will get mfn from pod cache and set entry。 >> but i did not know why call

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

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. CC: Matt Fleming Signed-off-by:

[Xen-devel] Ping: [PATCH] XSA-77: widen scope again

>>> On 29.04.16 at 11:35, wrote: > As discussed on the hackathon, avoid us having to issue security > advisories for issues affecting only heavily disaggregated tool stack > setups, which no-one appears to use (or else they should step up to get > things into shape). > >

Re: [Xen-devel] question about p2m_pod_demand_populate

>>> On 06.05.16 at 08:55, wrote: > in p2m_pod_demand_populate > i see： > p2m_pod_demand_populate >- pod_eager_reclaim >- pod_eager_record > > if gfn is pod， will get mfn from pod cache and set entry。 > but i did not know why call pod_eager_reclaim、pod_eager_record

Re: [Xen-devel] [PATCH for 4.7] pvusb: add missing definition to usbif.h

>>> On 06.05.16 at 09:49, wrote: On 06.05.16 at 07:01, wrote: >> On 05/05/16 11:22, Wei Liu wrote: >>> On Thu, May 05, 2016 at 11:10:33AM +0200, Juergen Gross wrote: On 05/05/16 11:02, Wei Liu wrote: > On Thu, May 05, 2016 at 08:36:45AM +0200,

Re: [Xen-devel] [PATCH for 4.7] pvusb: add missing definition to usbif.h

>>> On 06.05.16 at 07:01, wrote: > On 05/05/16 11:22, Wei Liu wrote: >> On Thu, May 05, 2016 at 11:10:33AM +0200, Juergen Gross wrote: >>> On 05/05/16 11:02, Wei Liu wrote: On Thu, May 05, 2016 at 08:36:45AM +0200, Juergen Gross wrote: > The pvusb request structure

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

flight 44393 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44393/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-armhf-pvops 3 host-install(3) broken like 44370 build-armhf

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

On May 06, 2016 3:03 PM, Jan Beulich wrote: > >>> On 05.05.16 at 12:18, wrote: > > What about this one as below: > > If done properly (coding style, comments to silence Coverity, consistency > throughout not just your change, but its effects on the rest of

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

>>> On 05.05.16 at 12:18, wrote: > What about this one as below: If done properly (coding style, comments to silence Coverity, consistency throughout not just your change, but its effects on the rest of the code in that file), that's certainly an option. Jan > ---

[Xen-devel] question about p2m_pod_demand_populate

hi all in p2m_pod_demand_populate i see： p2m_pod_demand_populate - pod_eager_reclaim - pod_eager_record if gfn is pod， will get mfn from pod cache and set entry。 but i did not know why call pod_eager_reclaim、pod_eager_record in p2m_pod_demand_populate？ what the purpose for

Re: [Xen-devel] [PATCH v2 for-4.7 5/6] xen/xsplice: add ELFOSABI_FREEBSD as a supported OSABI for payloads

>>> On 05.05.16 at 18:35, wrote: > On Wed, May 04, 2016 at 04:34:26AM -0600, Jan Beulich wrote: >> >>> On 04.05.16 at 11:48, wrote: >> > On Tue, May 03, 2016 at 08:17:15AM -0600, Jan Beulich wrote: >> >> >>> On 03.05.16 at 12:55,