[Xen-devel] [xen-4.6-testing baseline-only test] 71301: regressions - FAIL

This run is configured for baseline tests only. flight 71301 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71301/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvh-amd 6 xen-boot

[Xen-devel] [xen-unstable test] 109350: regressions - FAIL

flight 109350 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/109350/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 17 guest-start/win.repeat fail in 109309 REGR. vs.

[Xen-devel] [Outreachy] Adding Floating Point support to Mini-OS Project

Hello Juergen, I've learnt about your project through the Outreachy Projects List . I'm currently on the third year of my computer science bachelors course and I'm very much interested to know more about the project you proposed, since

Re: [Xen-devel] null domains after xl destroy

On 09/05/17 21:24, Roger Pau Monné wrote: On Mon, May 08, 2017 at 11:10:24AM +0200, Juergen Gross wrote: On 04/05/17 00:17, Glenn Enright wrote: On 04/05/17 04:58, Steven Haigh wrote: On 04/05/17 01:53, Juergen Gross wrote: On 03/05/17 12:45, Steven Haigh wrote: Just wanted to give this a

Re: [Xen-devel] Proposal to allow setting up shared memory areas between VMs from xl config file

2017-05-13 1:51 GMT+08:00 Wei Liu : > Hi Zhongze > > This is a nice write-up. Some comments below. Feel free to disagree with > what I say below, this is more a discussion than picking on your design > or plan. > HI, Wei Liu Thanks for your time reading through my proposal.

[Xen-devel] [linux-next test] 109349: regressions - FAIL

flight 109349 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/109349/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl 9 debian-install fail REGR. vs. 109315 Tests which did not

[Xen-devel] [XEN-devel] arm64: fix incorrect pa_range_info table to support 42 bit PA systems.

The pa_range_info table contain incorrect root_order and t0sz which prevent 42 bit PA systems from booting dom0. Signed-off-by: Feng Kan --- xen/arch/arm/p2m.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index

[Xen-devel] [xen-4.7-testing baseline-only test] 71300: tolerable trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71300 xen-4.7-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71300/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-qemuu-nested-intel 16

Re: [Xen-devel] [PATCH v3 04/29] x86: assembly, use ENDPROC for functions

On Fri, May 12, 2017 at 09:53:48AM +0200, Jiri Slaby wrote: > On 04/26/2017, 03:42 AM, Josh Poimboeuf wrote: > >> @@ -323,7 +323,7 @@ ENTRY(resume_userspace) > >>movl%esp, %eax > >>callprepare_exit_to_usermode > >>jmp restore_all > >> -END(ret_from_exception) > >>

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

flight 109351 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/109351/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 5 xen-buildfail REGR. vs. 107636 build-arm64

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-qemut-win7-amd64

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemut-win7-amd64 testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu

[Xen-devel] [libvirt test] 109340: tolerable all pass - PUSHED

flight 109340 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/109340/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 109301 test-armhf-armhf-libvirt 13

[Xen-devel] [linux-4.9 test] 109338: regressions - FAIL

flight 109338 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/109338/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358 Tests which are

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

Stefano, On 12 May 2017 at 21:43, Stefano Stabellini wrote: > On the topic of the technical reasons for being out of the hypervisor > (EL0 app or stubdom), I'll spend a couple of words on security. > > How large are these components? If they increase the hypervisor code

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Hi George, On 12 May 2017 at 14:48, George Dunlap wrote: > [reordering slightly to make the response easier] >> Okay, I don't know no platform where you need proprietary blob to >> scale frequency. And I hope, I never will encounter one. >> But I can imagine it: some

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

On Fri, 12 May 2017, George Dunlap wrote: > So given your examples, I see no reason not to have several > implementations of different mediators or emulated devices in tree, or > in a XenProject-managed git repo (like mini-os.git). I don't know the > particulars about mediators or the devices you

Re: [Xen-devel] [PATCH v2 03/18] x86/traps: lift do_guest_trap to domain.h

On 12/05/17 19:16, Andrew Cooper wrote: > On 05/05/17 15:48, Wei Liu wrote: >> Put it along side with other pv_inject functions and rename it to >> pv_inject_trap. >> >> We need this because this function is used by PV emulation code and PV >> trap handling code, which will be split into different

[Xen-devel] [linux-linus test] 109334: regressions - FAIL

flight 109334 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/109334/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail REGR. vs. 59254

Re: [Xen-devel] [PATCH v2 03/18] x86/traps: lift do_guest_trap to domain.h

On 05/05/17 15:48, Wei Liu wrote: > Put it along side with other pv_inject functions and rename it to > pv_inject_trap. > > We need this because this function is used by PV emulation code and PV > trap handling code, which will be split into different files. > > No functional change. > >

Re: [Xen-devel] Proposal to allow setting up shared memory areas between VMs from xl config file

Hi Zhongze This is a nice write-up. Some comments below. Feel free to disagree with what I say below, this is more a discussion than picking on your design or plan. On Sat, May 13, 2017 at 01:01:39AM +0800, Zhongze Liu wrote: > Hi, Xen developers, > > I'm Zhongze Liu, a GSoC student of this

[Xen-devel] [xen-unstable-smoke test] 109359: tolerable trouble: broken/pass - PUSHED

flight 109359 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/109359/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 12

[Xen-devel] [PATCH v3 1/3] xen/string: Clean up {xen, arm}/string.h

* Drop __kernel_size_t entirely. It isn't useful distinction, especially as it means the the prototypes don't appear to match their common definitions. * Introduce __HAVE_ARCH_* guards for strpbrk(), strsep() and strspn(), which match their implementation in common/string.c * Apply

[Xen-devel] [PATCH v3 for-next 0/3] Improvements to string.h

This series has expanded a bit from its first version. It has been compile-checked on all architectures (locally and in Travis; https://travis-ci.org/andyhhp/xen/builds/231640889), and functionally tested on x86. Andrew Cooper (3): xen/string: Clean up {xen,arm}/string.h xen/string: Use

[Xen-devel] [PATCH v3 2/3] xen/string: Use compiler __builtin_*() where possible

The use of -fno-builtin inhibits these automatic transformations. This causes constructs such as strlen("literal") to be evaluated at compile time, and certain simple operations to be replaced with repeated string operations. To avoid the macro altering the function names, use the method

[Xen-devel] [PATCH v3 3/3] x86/string: Clean up x86/string.h

* None of the GCC docs mention memmove() in its list of builtins even today, but 4.1 does have the builtin, meaning that all currently supported compilers have it. * Consistently use Xen style, matching the common code, and introduce symbol definitions for function pointer use. No

Re: [Xen-devel] xl list command hangs

No, xenstored was not running. Instantiating the same resolved the issue. Thanks Roger for your guidance. On Fri, May 12, 2017 at 1:43 PM, Roger Pau Monné wrote: > On Thu, May 11, 2017 at 11:53:43PM +0530, Praveen Kumar wrote: > > Hi All, > > > > I am working with latest

[Xen-devel] Proposal to allow setting up shared memory areas between VMs from xl config file

Hi, Xen developers, I'm Zhongze Liu, a GSoC student of this year. Glad to meet you in the Xen Project. As an initial step to implementing my GSoC proposal, which is still a draft, I'm posting it here. And hope to hear from you your suggestions.

Re: [Xen-devel] [PATCH v1 06/10] iommu: Add extra use_iommu argument to iommu_domain_init()

Hi, Jan. On Fri, May 12, 2017 at 5:31 PM, Jan Beulich wrote: On 10.05.17 at 16:03, wrote: >> From: Oleksandr Tyshchenko >> >> The presence of this flag lets us know that the guest >> has devices which will most likely

Re: [Xen-devel] [PATCH v1 02/10] iommu: Add extra order argument to the IOMMU APIs and platform callbacks

On Fri, May 12, 2017 at 7:17 PM, Jan Beulich wrote: On 12.05.17 at 17:50, wrote: >> On Fri, May 12, 2017 at 5:23 PM, Jan Beulich wrote: >> On 10.05.17 at 16:03, wrote: @@ -771,6 +773,47 @@ int

Re: [Xen-devel] [PATCH for-4.9] ioemu-stubdom: don't link *-softmmu* and *-linux-user*

On Fri, May 12, 2017 at 04:21:06PM +0100, Wei Liu wrote: > They are generated by ./configure. Having them linked can cause race > between tools build and stubdom build. > > Signed-off-by: Wei Liu FTR Juergen told me on IRC: Reviewed-by: Juergen Gross

Re: [Xen-devel] [PATCH] include: fix build without C++ compiler installed

On Fri, May 12, 2017 at 12:52:54AM -0600, Jan Beulich wrote: > The rule for headers++.chk wants to move headers++.chk.new to the > designated target, which means we have to create that file in the first > place. > > Signed-off-by: Jan Beulich Reviewed-by: Wei Liu

Re: [Xen-devel] [PATCH v1 02/10] iommu: Add extra order argument to the IOMMU APIs and platform callbacks

>>> On 12.05.17 at 17:50, wrote: > On Fri, May 12, 2017 at 5:23 PM, Jan Beulich wrote: > On 10.05.17 at 16:03, wrote: >>> @@ -771,6 +773,47 @@ int amd_iommu_unmap_page(struct domain *d, unsigned >>> long gfn) >>> return 0;

Re: [Xen-devel] [PATCH v2 for-next 2/2] x86/string: Use compiler __builtin_str*() where possible

On 12/05/17 16:42, Julien Grall wrote: > Hi Andrew, > > On 12/05/17 16:30, Andrew Cooper wrote: >> On 12/05/17 15:56, Jan Beulich wrote: >> On 12.05.17 at 16:34, wrote: --- a/xen/include/asm-x86/string.h +++ b/xen/include/asm-x86/string.h @@ -10,4

Re: [Xen-devel] [PATCH v1 02/10] iommu: Add extra order argument to the IOMMU APIs and platform callbacks

Hi Jan. On Fri, May 12, 2017 at 5:23 PM, Jan Beulich wrote: On 10.05.17 at 16:03, wrote: >> @@ -771,6 +773,47 @@ int amd_iommu_unmap_page(struct domain *d, unsigned >> long gfn) >> return 0; >> } >> >> +/* TODO: Optimize by squashing

Re: [Xen-devel] [PATCH v2 for-next 2/2] x86/string: Use compiler __builtin_str*() where possible

Hi Andrew, On 12/05/17 16:30, Andrew Cooper wrote: On 12/05/17 15:56, Jan Beulich wrote: On 12.05.17 at 16:34, wrote: --- a/xen/include/asm-x86/string.h +++ b/xen/include/asm-x86/string.h @@ -10,4 +10,12 @@ #define __HAVE_ARCH_MEMSET #define memset(s, c, n)

Re: [Xen-devel] [PATCH v1 08/10] iommu: Split iommu_hwdom_init() into arch specific parts

>>> On 12.05.17 at 17:25, wrote: > On Fri, May 12, 2017 at 5:41 PM, Jan Beulich wrote: > On 10.05.17 at 16:03, wrote: >>> The "retrieving mapping" code has never executed since >>> iommu_use_hap_pt(d) always returned true on ARM

Re: [Xen-devel] [PATCH v2 for-next 2/2] x86/string: Use compiler __builtin_str*() where possible

>>> On 12.05.17 at 17:30, wrote: > Given that all supported compilers have these builtins, I think it might > be better to make this adjustment in common code. The arguments for > using them in x86 are the same as ARM. Generally I agree. But Linux not having used them

Re: [Xen-devel] [PATCH v2 for-next 1/2] x86/string: Clean up the declarations of __builtin_mem*()

>>> On 12.05.17 at 17:20, wrote: > On 12/05/17 15:52, Jan Beulich wrote: > On 12.05.17 at 16:34, wrote: >>> Rather than #undef'ing macros to avoid altering the function names, use the >>> method recommended by the C specification by

Re: [Xen-devel] [PATCH v9 08/28] ARM: introduce vgic_access_guest_memory()

Hi Andre, On 11/05/17 18:53, Andre Przywara wrote: From: Vijaya Kumar K This function allows to copy a chunk of data from and to guest physical memory. It looks up the associated page from the guest's p2m tree and maps this page temporarily for the time of the

Re: [Xen-devel] [PATCH v2 for-next 2/2] x86/string: Use compiler __builtin_str*() where possible

On 12/05/17 15:56, Jan Beulich wrote: On 12.05.17 at 16:34, wrote: >> --- a/xen/include/asm-x86/string.h >> +++ b/xen/include/asm-x86/string.h >> @@ -10,4 +10,12 @@ >> #define __HAVE_ARCH_MEMSET >> #define memset(s, c, n) __builtin_memset(s, c, n) >> >>

Re: [Xen-devel] [PATCH v1 08/10] iommu: Split iommu_hwdom_init() into arch specific parts

Hi, Jan. On Fri, May 12, 2017 at 5:41 PM, Jan Beulich wrote: On 10.05.17 at 16:03, wrote: >> The "retrieving mapping" code has never executed since >> iommu_use_hap_pt(d) always returned true on ARM so far. But, with >> introducing the non-shared

[Xen-devel] [ovmf baseline-only test] 71299: tolerable FAIL

This run is configured for baseline tests only. flight 71299 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71299/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-libvirt 5 libvirt-build

Re: [Xen-devel] [PATCH v9 07/28] ARM: vGICv3: handle virtual LPI pending and property tables

Hi Andre, On 11/05/17 18:53, Andre Przywara wrote: Allow a guest to provide the address and size for the memory regions it has reserved for the GICv3 pending and property tables. We sanitise the various fields of the respective redistributor registers. The MMIO read and write accesses are

[Xen-devel] [PATCH for-4.9] ioemu-stubdom: don't link *-softmmu* and *-linux-user*

They are generated by ./configure. Having them linked can cause race between tools build and stubdom build. Signed-off-by: Wei Liu --- Cc: Ian Jackson Cc: Juergen Gross Cc: Julien Grall Should fix

Re: [Xen-devel] [PATCH v2 for-next 1/2] x86/string: Clean up the declarations of __builtin_mem*()

On 12/05/17 15:52, Jan Beulich wrote: On 12.05.17 at 16:34, wrote: >> Rather than #undef'ing macros to avoid altering the function names, use the >> method recommended by the C specification by enclosing the function name in >> brackets to avoid the macro being

Re: [Xen-devel] Xen 4.9 rc4

Hello, On 12/05/17 15:33, Lars Kurth wrote: Removing the announce and user list. Could you please clarify if this [1] is still relevant? Yes I will let Julien answer the rest: the main goal is really to ensure that Xen 4.9 works with the HW you care about. Lars On 12/05/2017 15:29,

Re: [Xen-devel] [PATCH v2 for-next 2/2] x86/string: Use compiler __builtin_str*() where possible

>>> On 12.05.17 at 16:34, wrote: > --- a/xen/include/asm-x86/string.h > +++ b/xen/include/asm-x86/string.h > @@ -10,4 +10,12 @@ > #define __HAVE_ARCH_MEMSET > #define memset(s, c, n) __builtin_memset(s, c, n) > > +#define strcmp(s1, s2)

Re: [Xen-devel] [PATCH v9 05/28] ARM: GICv3: forward pending LPIs to guests

Hi Andre, On 11/05/17 18:53, Andre Przywara wrote: diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c index 44d2b50..87f58f6 100644 --- a/xen/arch/arm/vgic-v3.c +++ b/xen/arch/arm/vgic-v3.c @@ -1567,12 +1567,30 @@ static struct pending_irq *vgic_v3_lpi_to_pending(struct domain *d,

Re: [Xen-devel] [PATCH v2 for-next 1/2] x86/string: Clean up the declarations of __builtin_mem*()

>>> On 12.05.17 at 16:34, wrote: > Rather than #undef'ing macros to avoid altering the function names, use the > method recommended by the C specification by enclosing the function name in > brackets to avoid the macro being expanded. This means that optimisation >

Re: [Xen-devel] [PATCH v3 4/9] mm: Scrub memory from idle loop

On 05/12/2017 04:17 AM, Dario Faggioli wrote: > On Thu, 2017-05-11 at 13:05 -0400, Boris Ostrovsky wrote: >> On 05/11/2017 11:48 AM, Dario Faggioli wrote: >> >>> It probably would be at least a bit better, if scrub_free_pages() >>> would >>> check for softirqs() _before_ starting any scrubbing

Re: [Xen-devel] [PATCH v1 08/10] iommu: Split iommu_hwdom_init() into arch specific parts

>>> On 10.05.17 at 16:03, wrote: > The "retrieving mapping" code has never executed since > iommu_use_hap_pt(d) always returned true on ARM so far. But, with > introducing the non-shared IOMMU patch series we can no longer keep > this code as is due to the lack of M2P

Re: [Xen-devel] Xen 4.9 rc4

Removing the announce and user list. > Could you please clarify if this [1] is still relevant? Yes I will let Julien answer the rest: the main goal is really to ensure that Xen 4.9 works with the HW you care about. Lars On 12/05/2017 15:29, "Andrii Anisov" wrote:

[Xen-devel] [PATCH v2 for-next 2/2] x86/string: Use compiler __builtin_str*() where possible

The use of -fno-builtin inhibits this automatic transformation. Manually transform the callsites. This causes constructs such as strlen("literal") to be evaluated at compile time, and certain simple operations to be replaced with repeated string operations. Signed-off-by: Andrew Cooper

[Xen-devel] [PATCH v2 for-next 1/2] x86/string: Clean up the declarations of __builtin_mem*()

None of the GCC docs mention memmove() in its list of builtins even today, but 4.1 does have the builtin, meaning that all currently supported compilers have it. Rather than #undef'ing macros to avoid altering the function names, use the method recommended by the C specification by enclosing the

Re: [Xen-devel] [PATCH v1 07/10] iommu/arm: Add alloc_page_table platform callback

>>> On 11.05.17 at 20:06, wrote: > Hi Oleksandr, > > On 11/05/17 15:00, Oleksandr Tyshchenko wrote: >> On Thu, May 11, 2017 at 2:38 PM, Julien Grall wrote: >>> Hi Oleksandr, >> Hi, Julien >> >>> >>> On 10/05/17 15:03, Oleksandr Tyshchenko wrote:

Re: [Xen-devel] [PATCH v1 06/10] iommu: Add extra use_iommu argument to iommu_domain_init()

>>> On 10.05.17 at 16:03, wrote: > From: Oleksandr Tyshchenko > > The presence of this flag lets us know that the guest > has devices which will most likely be used for passthrough > and as the result the use of IOMMU is expected for this

Re: [Xen-devel] Xen 4.9 rc4

Dear Julien, On 08.05.17 21:41, Julien Grall wrote: As a reminder, there will be another Xen Test Day tomorrow (Tuesday 9th May), for the instructions see: https://blog.xenproject.org/2017/04/13/announcing-xen-project-4-9-rc-and-test-day-schedule/ Cheers, I'm asked to perform a XEN

Re: [Xen-devel] [PATCH v1 02/10] iommu: Add extra order argument to the IOMMU APIs and platform callbacks

>>> On 10.05.17 at 16:03, wrote: > @@ -771,6 +773,47 @@ int amd_iommu_unmap_page(struct domain *d, unsigned long > gfn) > return 0; > } > > +/* TODO: Optimize by squashing map_pages/unmap_pages with > map_page/unmap_page */ Looking over the titles of the rest of

Re: [Xen-devel] [PATCH v9 04/28] ARM: GICv3: introduce separate pending_irq structs for LPIs

Hi Andre, On 11/05/17 18:53, Andre Przywara wrote: For the same reason that allocating a struct irq_desc for each possible LPI is not an option, having a struct pending_irq for each LPI is also not feasible. We only care about mapped LPIs, so we can get away with having struct pending_irq's

Re: [Xen-devel] [PATCH v9 03/28] ARM: GIC: Add checks for NULL pointer pending_irq's

Hi Andre, On 11/05/17 18:53, Andre Przywara wrote: For LPIs the struct pending_irq's are dynamically allocated and the pointers will be stored in a radix tree. Since an LPI can be "unmapped" at any time, teach the VGIC how to deal with irq_to_pending() returning a NULL pointer. We just do

Re: [Xen-devel] arm64: incorrect pa setup cause dom0 boot failure

Hi, On 11/05/17 19:24, Feng Kan wrote: Ian: Ian left Citrix a year ago. I would recommend you to CC ARM maintainers (Stefano and I) if you want to get a prompt answer. Just a quick question regarding the table below in xen/arch/arm/p2m.c @@ -1479,7 +1487,7 @@ void __init

Re: [Xen-devel] [PATCH v2 3/3] x86/vioapic: bind interrupts to PVH Dom0

>>> On 19.04.17 at 17:11, wrote: > --- a/xen/arch/x86/hvm/vioapic.c > +++ b/xen/arch/x86/hvm/vioapic.c > @@ -158,6 +158,62 @@ static int vioapic_read( > return X86EMUL_OKAY; > } > > +static int vioapic_dom0_map_gsi(unsigned int gsi, unsigned int trig, Considering

Re: [Xen-devel] [PATCH 2/2] xen/input: add multi-touch support

gentle reminder On 05/05/2017 07:45 AM, Oleksandr Andrushchenko wrote: Hi, Dmitry! On 04/21/2017 09:40 AM, Oleksandr Andrushchenko wrote: Hi, Dmitry! On 04/21/2017 05:10 AM, Dmitry Torokhov wrote: Hi Oleksandr, On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:

Re: [Xen-devel] [PATCH 1/2] xen/input: use string constants from PV protocol

gentle reminder On 05/05/2017 07:43 AM, Oleksandr Andrushchenko wrote: Hello, Dmitry! On 04/21/2017 09:42 AM, Oleksandr Andrushchenko wrote: On 04/21/2017 05:11 AM, Dmitry Torokhov wrote: On Thu, Apr 13, 2017 at 02:38:03PM +0300, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko

Re: [Xen-devel] [PATCH v2 2/3] x86/pt: enable binding of GSIs to a PVH Dom0

>>> On 19.04.17 at 17:11, wrote: > Note that currently there's no support for unbinding this interrupts. Do you plan to deal with that before this changes goes in? Aiui this not working means you can't pass through devices with pin based interrupts once Dom0 chose to bind

Re: [Xen-devel] [PATCH] tools: don't require unavailable optional libraries in pkg-config files

Juergen Gross writes ("[PATCH] tools: don't require unavailable optional libraries in pkg-config files"): > blktap2 is optional, so there should be no pkg-config file requiring > xenblktapctl if it isn't enabled for the build. > > Add a filter mechanism to tools/Rules.mk to filter out optional >

Re: [Xen-devel] [PATCH] tools: don't require unavailable optional libraries in pkg-config files

On Fri, May 12, 2017 at 03:10:51PM +0200, Juergen Gross wrote: > blktap2 is optional, so there should be no pkg-config file requiring > xenblktapctl if it isn't enabled for the build. > > Add a filter mechanism to tools/Rules.mk to filter out optional > libraries. > > Signed-off-by: Juergen

[Xen-devel] [xen-unstable-smoke test] 109353: tolerable trouble: broken/pass - PUSHED

flight 109353 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/109353/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 12

[Xen-devel] [PATCH] tools: don't require unavailable optional libraries in pkg-config files

blktap2 is optional, so there should be no pkg-config file requiring xenblktapctl if it isn't enabled for the build. Add a filter mechanism to tools/Rules.mk to filter out optional libraries. Signed-off-by: Juergen Gross --- tools/Rules.mk | 9 +++-- 1 file changed, 7

Re: [Xen-devel] [PATCH v2 1/3] x86/physdev: factor out the code to allocate and map a pirq

>>> On 19.04.17 at 17:11, wrote: > +int allocate_and_map_gsi_pirq(struct domain *d, int *index, int *pirq_p) > +{ > +int irq, pirq, ret; > + > +if ( *index < 0 || *index >= nr_irqs_gsi ) > +{ > +dprintk(XENLOG_G_ERR, "dom%d: map invalid irq %d\n",

[Xen-devel] [xen-4.6-testing baseline-only test] 71254: regressions - FAIL

This run is configured for baseline tests only. flight 71254 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71254/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-420

Re: [Xen-devel] [For Xen-4.10 RFC PATCH 3/3] Prevent redundant icache flushes in populate_physmap()

Hi Julien, Julien Grall writes: > Hi Punit, > > Sorry for the late answer. > > On 31/03/17 11:24, Punit Agrawal wrote: >> populate_physmap() calls alloc_heap_pages() per requested extent. As >> alloc_heap_pages() performs icache maintenance operations affecting the >>

Re: [Xen-devel] Is there any limitation on the firmware size in Xen?

>>> On 12.05.17 at 12:06, wrote: > On Fri, May 12, 2017 at 07:32:49PM +1000, Jan Beulich wrote: >> >>> On 11.05.17 at 11:02, wrote: >> > On Thu, May 11, 2017 at 06:14:42PM +1000, Jan Beulich wrote: >> >> Note that hvmloader's main() has >> >> >> >>

Re: [Xen-devel] Is there any limitation on the firmware size in Xen?

>>> On 12.05.17 at 12:11, wrote: > On 12/05/17 10:32, Jan Beulich wrote: >> --- a/tools/firmware/hvmloader/tests.c >> +++ b/tools/firmware/hvmloader/tests.c > > In the presence of XTF regression tests being run in OSSTest, this > entire mechanism in HVMLoader ought to

[Xen-devel] [xen-4.7-testing baseline-only test] 71251: tolerable trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71251 xen-4.7-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71251/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-qemuu-nested-intel 16

Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface

On Thu, May 4, 2017 at 11:49 AM, Oleksandr Grytsov wrote: > Hi All, > > Here is configuration proposal with connector (surface) id: > > 1. Configuration file: > vdispl = [ 'backend=0, devId=0, beAlloc=1, > connectors=id0:800x600;id1:1024x768' ] > > * backend - backend domain

Re: [Xen-devel] [PATCH v2 05/18] x86/pv: clean up emulate_ops.c

On Fri, May 12, 2017 at 01:02:04PM +0100, Wei Liu wrote: > On Thu, May 11, 2017 at 12:22:29PM +0100, Andrew Cooper wrote: > > Please can you fold this following delta? > > Actually I'm going to combine your patch with mine #5. Oops, I thought you were replying to #4...

Re: [Xen-devel] [PATCH v2 05/18] x86/pv: clean up emulate_ops.c

On Thu, May 11, 2017 at 12:22:29PM +0100, Andrew Cooper wrote: > Please can you fold this following delta? Actually I'm going to combine your patch with mine #5. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 04/18] x86/traps: move all PV emulation code to pv/emulate_ops.h

On Thu, May 11, 2017 at 11:18:39AM +0100, Andrew Cooper wrote: > On 05/05/17 15:48, Wei Liu wrote: > > Move the following emulation code from traps.c: > > > > 1. invalid op > > 2. rdtsc > > 3. privilege instructions > > 4. gate operation > > 5. pv cpuid emulation > > > > Export the emulate_*

Re: [Xen-devel] [PATCH v2 01/18] x86/traps: factor out pv_percpu_traps_init

On Fri, May 05, 2017 at 05:12:25PM +0100, Andrew Cooper wrote: > On 05/05/17 15:48, Wei Liu wrote: > > The body of subarch_percpu_traps_init is for setting up PV syscall > > trampoline. Move that into a dedicated function. > > > > Leave the BUILD_BUG_ON in the original function as it is not tied

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

[reordering slightly to make the response easier] On Thu, May 11, 2017 at 7:13 PM, Volodymyr Babchuk wrote: >> Maybe I'm just not familiar with things, but it's hard for me to imagine >> why you'd need proprietary blobs to disable cpus or scale frequency. >> Are these

[Xen-devel] [ovmf test] 109347: all pass - PUSHED

flight 109347 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/109347/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 760759962786c3c554c20d76b800ee31a878aaa1 baseline version: ovmf

Re: [Xen-devel] Enabling VT-d PI by default

On 27/04/17 08:08, Jan Beulich wrote: On 26.04.17 at 19:11, wrote: >> On 18/04/17 07:24, Tian, Kevin wrote: From: Gao, Chao Sent: Monday, April 17, 2017 4:14 AM On Tue, Apr 11, 2017 at 02:21:07AM -0600, Jan Beulich wrote: On 11.04.17 at

[Xen-devel] [ovmf baseline-only test] 71294: tolerable FAIL

This run is configured for baseline tests only. flight 71294 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71294/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-libvirt 5 libvirt-build

[Xen-devel] Xen Security Advisory 213 (CVE-2017-8903) - x86: 64bit PV guest breakout via pagetable use-after-mode-change

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-8903 / XSA-213 version 3 x86: 64bit PV guest breakout via pagetable use-after-mode-change UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION

[Xen-devel] Xen Security Advisory 214 (CVE-2017-8904) - grant transfer allows PV guest to elevate privileges

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-8904 / XSA-214 version 3 grant transfer allows PV guest to elevate privileges UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION

[Xen-devel] Xen Security Advisory 215 (CVE-2017-8905) - possible memory corruption via failsafe callback

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-8905 / XSA-215 version 3 possible memory corruption via failsafe callback UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION

Re: [Xen-devel] Is there any limitation on the firmware size in Xen?

On 12/05/17 10:32, Jan Beulich wrote: On 11.05.17 at 11:02, wrote: >> On Thu, May 11, 2017 at 06:14:42PM +1000, Jan Beulich wrote: >>> Note that hvmloader's main() has >>> >>> BUG_ON(hvm_start_info->magic != XEN_HVM_START_MAGIC_VALUE); >>> >>> very early, so you having got

Re: [Xen-devel] Is there any limitation on the firmware size in Xen?

On Fri, May 12, 2017 at 07:32:49PM +1000, Jan Beulich wrote: > >>> On 11.05.17 at 11:02, wrote: > > On Thu, May 11, 2017 at 06:14:42PM +1000, Jan Beulich wrote: > >> Note that hvmloader's main() has > >> > >> BUG_ON(hvm_start_info->magic != XEN_HVM_START_MAGIC_VALUE); > >> >

Re: [Xen-devel] [Patch] Fix broken package config file xenlight.pc.in

On Fri, May 12, 2017 at 10:44:34AM +0200, Juergen Gross wrote: > On 12/05/17 10:15, Roger Pau Monné wrote: > > On Thu, May 11, 2017 at 10:29:42AM -0600, Charles Arnold wrote: > >> The Requires line in this config file uses the wrong names for two > >> dependencies. > >> > >> The package config

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

flight 109331 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/109331/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 5 xen-buildfail REGR. vs. 107636 build-arm64

Re: [Xen-devel] Is there any limitation on the firmware size in Xen?

>>> On 11.05.17 at 11:02, wrote: > On Thu, May 11, 2017 at 06:14:42PM +1000, Jan Beulich wrote: >> Note that hvmloader's main() has >> >> BUG_ON(hvm_start_info->magic != XEN_HVM_START_MAGIC_VALUE); >> >> very early, so you having got past this means the corruption >> occurred

Re: [Xen-devel] [PATCH 06/12 v3] xen/arm: vpl011: Add a new vuart node in the xenstore

Hi Wei, On 11 May 2017 at 16:40, Wei Liu wrote: > On Wed, May 10, 2017 at 08:05:12PM +0530, Bhupinder Thakur wrote: >> libxl__device_console_add(gc, domid, , state, ); >> @@ -1369,14 +1377,22 @@ static void domcreate_launch_dm(libxl__egc *egc, >> libxl__multidev

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

flight 109326 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/109326/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-winxpsp3 17 guest-start/win.repeat fail REGR. vs. 109165

Re: [Xen-devel] [Patch] Fix broken package config file xenlight.pc.in

On 12/05/17 10:15, Roger Pau Monné wrote: > On Thu, May 11, 2017 at 10:29:42AM -0600, Charles Arnold wrote: >> The Requires line in this config file uses the wrong names for two >> dependencies. >> >> The package config file for xenctrl is called 'xencontrol' and for blktapctl >> is >> called

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

flight 71293 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71293/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-armhf-jessie-netboot-pygrub 1 build-check(1) blocked n/a build-arm64

[Xen-devel] [PATCH V5] x86/ioreq_server: Make p2m_finish_type_change actually work

Commit 6d774a951696 ("x86/ioreq server: synchronously reset outstanding p2m_ioreq_server entries when an ioreq server unmaps") introduced p2m_finish_type_change(), which was meant to synchronously finish a previously initiated type change over a gpfn range. It did this by calling get_entry(),

[Xen-devel] [ovmf test] 109344: all pass - PUSHED

flight 109344 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/109344/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf db55dac77579fa2722e4457bfc4369f98b8ff52a baseline version: ovmf

Re: [Xen-devel] [PATCH v2 2/5] vcpu: track hvm vcpu number on the system

On Thu, May 11, 2017 at 12:37:37PM +0100, Wei Liu wrote: >On Thu, May 11, 2017 at 12:35:11PM +0100, Wei Liu wrote: >> On Thu, May 11, 2017 at 02:04:09PM +0800, Chao Gao wrote: >> > This number is used to calculate how many hvm vcpu on a pcpu on average. >> > >> > Signed-off-by: Chao Gao

Re: [Xen-devel] [PATCH v3 4/9] mm: Scrub memory from idle loop

On Thu, 2017-05-11 at 13:05 -0400, Boris Ostrovsky wrote: > On 05/11/2017 11:48 AM, Dario Faggioli wrote: > > > It probably would be at least a bit better, if scrub_free_pages() > > would > > check for softirqs() _before_ starting any scrubbing (which I don't > > think it does, right now, am I

  1   2   >