Re: [Xen-devel] [PATCH] xen/x86: Do not call xen_init_time_ops() until shared_info is initialized

On 03/05/17 22:20, Boris Ostrovsky wrote: > Routines that are set by xen_init_time_ops() use shared_info's > pvclock_vcpu_time_info area. This area is not properly available until > shared_info is mapped in xen_setup_shared_info(). > > This became especially problematic due to commit dd759d93f4dd

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

flight 108184 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/108184/ 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] [PATCH v2] xen/arm32: Distinguish guest SError from Xen data aborts

ARM32 doesn't have an exception similar to hyp_sync of ARM64 to catch the synchronous data abort (For example, a NULL pointer has been referenced). Hence the SError and sync data abort will be caught by the same data abort exception. Since commit "3f16c8cb" we treat all data aborts caught by this

[Xen-devel] [PATCH]acpi: enlarge NUM_FIXMAP_ACPI_PAGES from 4 to 5

In __acpi_map_table(), it suppose all ACPI tables may not exceed 4 pages. but nowadays ACPI tables, such as SRAT table, are large enough, On my BIOS board, the SRAT table achieves the size of 14428B, although it's above 3 pages and within 4pages, but in __acpi_map_table(), it maps p

[Xen-devel] [seabios baseline-only test] 71250: regressions - FAIL

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

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

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

[Xen-devel] [xen-4.6-testing test] 108176: tolerable FAIL - PUSHED

flight 108176 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/108176/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-i386-pvgrub 9 debian-di-install fail in 108138 pass in 108176 test-amd64-i386-xl-qemuu-debi

Re: [Xen-devel] [PATCH] xen/arm32: Distinguish guest SError from Xen data aborts

Hi Stefano, On 2017/5/4 5:56, Stefano Stabellini wrote: > On Wed, 3 May 2017, Wei Chen wrote: >> ARM32 doesn't have an exception similar to hyp_sync of ARM64 to catch >> the synchronous data abort (For example, a NULL pointer has been referenced). >> Hence the SError and sync data abort will be ca

[Xen-devel] [xen-4.8-testing test] 108169: tolerable FAIL - PUSHED

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

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

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

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

On Wed, May 03, 2017 at 04:12:29PM -0700, Stefano Stabellini wrote: > On Wed, 3 May 2017, Greg KH wrote: > > On Wed, May 03, 2017 at 03:59:15PM -0700, Stefano Stabellini wrote: > > > On Wed, 3 May 2017, Boris Ostrovsky wrote: > > > > On 05/03/2017 02:19 PM, David Woodhouse wrote: > > > > > On Wed,

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

On Wed, 3 May 2017, Greg KH wrote: > On Wed, May 03, 2017 at 03:59:15PM -0700, Stefano Stabellini wrote: > > On Wed, 3 May 2017, Boris Ostrovsky wrote: > > > On 05/03/2017 02:19 PM, David Woodhouse wrote: > > > > On Wed, 2017-02-22 at 10:14 -0500, Boris Ostrovsky wrote: > > > >> On 02/22/2017 09:28

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

On Wed, May 03, 2017 at 03:59:15PM -0700, Stefano Stabellini wrote: > On Wed, 3 May 2017, Boris Ostrovsky wrote: > > On 05/03/2017 02:19 PM, David Woodhouse wrote: > > > On Wed, 2017-02-22 at 10:14 -0500, Boris Ostrovsky wrote: > > >> On 02/22/2017 09:28 AM, Bjorn Helgaas wrote: > > >>> On Tue, Feb

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

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

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

On Wed, 3 May 2017, Boris Ostrovsky wrote: > On 05/03/2017 02:19 PM, David Woodhouse wrote: > > On Wed, 2017-02-22 at 10:14 -0500, Boris Ostrovsky wrote: > >> On 02/22/2017 09:28 AM, Bjorn Helgaas wrote: > >>> On Tue, Feb 21, 2017 at 10:58:39AM -0500, Boris Ostrovsky wrote: > On 02/21/2017 10:

[Xen-devel] [xen-4.7-testing test] 108166: tolerable FAIL - PUSHED

flight 108166 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/108166/ 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 108137 pass in 108166 test-armhf-

Re: [Xen-devel] [PATCH 06/10 v2] xen/arm: vpl011: Add vuart ring-buf and evtchn to xenstore

On Wed, 3 May 2017, Bhupinder Thakur wrote: > Hi, > > >> > It looks like you are reusing the libxl__device_console_add call for the > >> > main PV console for the domain, to also add the vuart nodes to xenstore. > >> > > >> > I don't think it is a good idea to mix the two. I suggest to introduce a

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

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 little nudge now people seem to be back on deck... Glenn, could you please give the attached patch a try? It should be applied on top of the other

Re: [Xen-devel] [PATCH] xen/arm32: Distinguish guest SError from Xen data aborts

On Wed, 3 May 2017, Wei Chen wrote: > ARM32 doesn't have an exception similar to hyp_sync of ARM64 to catch > the synchronous data abort (For example, a NULL pointer has been referenced). > Hence the SError and sync data abort will be caught by the same data abort > exception. > > Since commit "3f

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

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

[Xen-devel] [PATCH v2] xen/mapcache: store dma information in revmapcache entries for debugging

The Xen mapcache is able to create long term mappings, they are called "locked" mappings. The third parameter of the xen_map_cache call specifies if a mapping is a "locked" mapping. >From the QEMU point of view there are two kinds of long term mappings: [a] device memory mappings, such as option

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

flight 108164 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/108164/ 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 faili

Re: [Xen-devel] [PATCH v7 2/3] * util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64

On Wed, 3 May 2017, Andrew Cooper wrote: > On 02/05/17 08:06, fu@linaro.org wrote: > > From: Fu Wei > > > > This patch adds the support of xen_boot command for aarch64: > > xen_hypervisor > > xen_module > > These two commands are only for aarch64, since it has its own protocol and > >

Re: [Xen-devel] [PATCH v3 2/2][XTF] xtf/vpmu: MSR read/write tests for VPMU

On 25/04/17 22:45, Mohit Gambhir wrote: >>> diff --git a/tests/vpmu/Makefile b/tests/vpmu/Makefile >>> new file mode 100644 >>> index 000..1eaf436 >>> --- /dev/null >>> +++ b/tests/vpmu/Makefile >>> @@ -0,0 +1,9 @@ >>> +include $(ROOT)/build/common.mk >>> + >>> +NAME := vpmu >>> +CATEGORY

Re: [Xen-devel] QEMU build breakage on ARM against Xen 4.9 caused by libxendevicemodel

On Wed, 3 May 2017, Stefano Stabellini wrote: > On Wed, 3 May 2017, Anthony PERARD wrote: > > On Wed, May 03, 2017 at 10:20:59AM -0700, Stefano Stabellini wrote: > > > On Wed, 3 May 2017, Anthony PERARD wrote: > > > > On Thu, Apr 20, 2017 at 11:05:33AM -0700, Stefano Stabellini wrote: > > > > > On

Re: [Xen-devel] [PATCH V2 1/2] x86/vm_event: added hvm/vm_event.{h, c}

On 05/03/2017 11:32 PM, Tamas K Lengyel wrote: > On Wed, May 3, 2017 at 4:16 PM, Razvan Cojocaru > wrote: >> On 05/03/2017 11:05 PM, Tamas K Lengyel wrote: >>> >>> >>> On Wed, May 3, 2017 at 6:48 AM, Jan Beulich >> > wrote: >>> >>> >>> On 03.05.17 at 12:37, >>

Re: [Xen-devel] [PATCH V2 1/2] x86/vm_event: added hvm/vm_event.{h, c}

On Wed, May 3, 2017 at 4:16 PM, Razvan Cojocaru wrote: > On 05/03/2017 11:05 PM, Tamas K Lengyel wrote: >> >> >> On Wed, May 3, 2017 at 6:48 AM, Jan Beulich > > wrote: >> >> >>> On 03.05.17 at 12:37, > > wrote: >> > On 05/03/17 12

Re: [Xen-devel] QEMU build breakage on ARM against Xen 4.9 caused by libxendevicemodel

On Wed, 3 May 2017, Anthony PERARD wrote: > On Wed, May 03, 2017 at 10:20:59AM -0700, Stefano Stabellini wrote: > > On Wed, 3 May 2017, Anthony PERARD wrote: > > > On Thu, Apr 20, 2017 at 11:05:33AM -0700, Stefano Stabellini wrote: > > > > On Thu, 20 Apr 2017, Paul Durrant wrote: > > > > > I think

[Xen-devel] [PATCH] xen/x86: Do not call xen_init_time_ops() until shared_info is initialized

Routines that are set by xen_init_time_ops() use shared_info's pvclock_vcpu_time_info area. This area is not properly available until shared_info is mapped in xen_setup_shared_info(). This became especially problematic due to commit dd759d93f4dd ("x86/timers: Add simple udelay calibration") where

Re: [Xen-devel] [PATCH V2 1/2] x86/vm_event: added hvm/vm_event.{h, c}

On 05/03/2017 11:05 PM, Tamas K Lengyel wrote: > > > On Wed, May 3, 2017 at 6:48 AM, Jan Beulich > wrote: > > >>> On 03.05.17 at 12:37, > wrote: > > On 05/03/17 12:51, Jan Beulich wrote: > > On 03.05.17 at 11:10,

[Xen-devel] [seabios test] 108165: tolerable FAIL - PUSHED

flight 108165 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/108165/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 107954 test-amd64-amd64-xl-qemuu-win7-amd64 15 g

Re: [Xen-devel] [PATCH V2 2/2] x86/vm_event: fix race between __context_switch() and vm_event_resume()

On Wed, May 3, 2017 at 5:10 AM, Razvan Cojocaru wrote: > > The introspection agent can reply to a vm_event faster than > vmx_vmexit_handler() can complete in some cases, where it is then > not safe for vm_event_set_registers() to modify v->arch.user_regs. > In the test scenario, we were stepping o

Re: [Xen-devel] [PATCH v3 0/2][XTF] xtf/vpmu VPMU tests

On 28/04/17 20:35, Mohit Gambhir wrote: > > > On 04/25/2017 02:50 PM, Andrew Cooper wrote: >> On 24/04/17 18:54, Mohit Gambhir wrote: >>> Mohit Gambhir (2): >>>xtf/vpmu: Add Intel PMU MSR addresses >>>xtf/vpmu: MSR read/write tests for VPMU >>> >>> arch/x86/include/arch/msr-index.h | 11

Re: [Xen-devel] [PATCH V2 1/2] x86/vm_event: added hvm/vm_event.{h, c}

On Wed, May 3, 2017 at 6:48 AM, Jan Beulich wrote: > >>> On 03.05.17 at 12:37, wrote: > > On 05/03/17 12:51, Jan Beulich wrote: > > On 03.05.17 at 11:10, wrote: > >>> --- /dev/null > >>> +++ b/xen/arch/x86/hvm/vm_event.c > >>> @@ -0,0 +1,101 @@ > >>> +/* > >>> + * arch/x86/hvm/vm_event.c >

Re: [Xen-devel] [PATCH v7 2/3] * util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64

On 02/05/17 08:06, fu@linaro.org wrote: > From: Fu Wei > > This patch adds the support of xen_boot command for aarch64: > xen_hypervisor > xen_module > These two commands are only for aarch64, since it has its own protocol and > commands to boot xen hypervisor and Dom0, but not multibo

Re: [Xen-devel] [PATCH] x86: polish __{get,put}_user_{,no}check()

On 02/05/17 15:40, Jan Beulich wrote: On 02.05.17 at 16:28, wrote: >> On 02/05/17 14:23, Jan Beulich wrote: >>> The primary purpose is correcting a latent bug in __get_user_check() >>> (the macro has no active user at present): The access_ok() check should >>> be before the actual access, or

Re: [Xen-devel] [PATCH] x86: correct create_bounce_frame

On 03/05/17 16:42, Jan Beulich wrote: On 02.05.17 at 16:12, wrote: >> On 02/05/17 14:22, Jan Beulich wrote: >>> @@ -345,15 +344,20 @@ UNLIKELY_START(z, create_bounce_frame_ba >>> __UNLIKELY_END(create_bounce_frame_bad_bounce_ip) >>> movq %rax,UREGS_rip+8(%rsp) >>> ret >>>

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

On 05/03/2017 02:19 PM, David Woodhouse wrote: > On Wed, 2017-02-22 at 10:14 -0500, Boris Ostrovsky wrote: >> On 02/22/2017 09:28 AM, Bjorn Helgaas wrote: >>> On Tue, Feb 21, 2017 at 10:58:39AM -0500, Boris Ostrovsky wrote: On 02/21/2017 10:45 AM, Juergen Gross wrote: > On 21/02/17 16:31,

Re: [Xen-devel] [PATCH 5/7] x86/traps: Lift all non-entrypoint logic in entry_int82() up into C

On 03/05/17 13:37, Jan Beulich wrote: On 03.05.17 at 14:18, wrote: >> On 03/05/17 13:02, Jan Beulich wrote: >> On 03.05.17 at 13:38, wrote: On 03/05/17 12:26, Wei Liu wrote: > On Wed, May 03, 2017 at 03:02:25AM -0600, Jan Beulich wrote: > On 02.05.17 at 20:05, wrote: >>

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

On Wed, 2017-02-22 at 10:14 -0500, Boris Ostrovsky wrote: > On 02/22/2017 09:28 AM, Bjorn Helgaas wrote: > > > > On Tue, Feb 21, 2017 at 10:58:39AM -0500, Boris Ostrovsky wrote: > > > > > > On 02/21/2017 10:45 AM, Juergen Gross wrote: > > > > > > > > On 21/02/17 16:31, Dan Streetman wrote: > > >

[Xen-devel] [PATCH v2 7/7] x86/asm: Clobber %r{8..15} on exit to 32bit PV guests

In the presence of bugs such as XSA-214 where a 32bit PV guest can get its hands on a long mode segment, this change prevents register content leaking between domains. Signed-off-by: Andrew Cooper --- CC: Jan Beulich v2: * Move to being in .else clauses --- xen/include/asm-x86/asm_defns.h | 1

Re: [Xen-devel] QEMU build breakage on ARM against Xen 4.9 caused by libxendevicemodel

On Wed, May 03, 2017 at 10:20:59AM -0700, Stefano Stabellini wrote: > On Wed, 3 May 2017, Anthony PERARD wrote: > > On Thu, Apr 20, 2017 at 11:05:33AM -0700, Stefano Stabellini wrote: > > > On Thu, 20 Apr 2017, Paul Durrant wrote: > > > > I think xencall should be part of the base xen_stable_libs a

[Xen-devel] [GIT PULL] xen: fixes and features for 4.12

Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.12b-rc0b-tag Main changes are: - a series by Vitaly Kuznetsov to enable building the kernel with Xen support but without enabling paravirtualized mode - a series by Stefano Stabell

Re: [Xen-devel] QEMU build breakage on ARM against Xen 4.9 caused by libxendevicemodel

On Wed, 3 May 2017, Anthony PERARD wrote: > On Thu, Apr 20, 2017 at 11:05:33AM -0700, Stefano Stabellini wrote: > > On Thu, 20 Apr 2017, Paul Durrant wrote: > > > I think xencall should be part of the base xen_stable_libs anyway. > > > > Yes, you are right. However I noticed that -lxencall needs t

Re: [Xen-devel] [PATCH v2] x86/vpmu_intel: Fix hypervisor crash by masking PC bit in MSR_P6_EVNTSEL

On 04/28/2017 02:52 AM, Tian, Kevin wrote: From: Tian, Kevin Sent: Friday, April 28, 2017 2:43 PM From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] Sent: Thursday, April 27, 2017 11:18 PM On 04/27/2017 11:05 AM, Jan Beulich wrote: On 27.04.17 at 16:57, wrote: On 04/27/2017 03:32 A

Re: [Xen-devel] [BUG] xl devd segmentation fault on xl block-detach

On Wed, May 03, 2017 at 03:31:58PM +0100, Wei Liu wrote: > On Wed, May 03, 2017 at 04:27:41PM +0300, Reinis Martinsons wrote: > > On 03.05.2017 13:27, Wei Liu wrote: > > libxl: debug: libxl_linux.c:200:libxl__get_hotplug_script_info: num_exec 1, > > not running hotplug scripts > > libxl: debug: li

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

On 04/05/17 01:53, Juergen Gross wrote: > On 03/05/17 12:45, Steven Haigh wrote: >> Just wanted to give this a little nudge now people seem to be back on >> deck... > > Glenn, could you please give the attached patch a try? > > It should be applied on top of the other correction, the old debug >

Re: [Xen-devel] QEMU build breakage on ARM against Xen 4.9 caused by libxendevicemodel

On Wed, May 03, 2017 at 05:52:07PM +0100, Wei Liu wrote: > On Wed, May 03, 2017 at 05:48:38PM +0100, Anthony PERARD wrote: > > On Thu, Apr 20, 2017 at 11:05:33AM -0700, Stefano Stabellini wrote: > > > On Thu, 20 Apr 2017, Paul Durrant wrote: > > > > I think xencall should be part of the base xen_st

Re: [Xen-devel] QEMU build breakage on ARM against Xen 4.9 caused by libxendevicemodel

> -Original Message- > From: Anthony PERARD [mailto:anthony.per...@citrix.com] > Sent: 03 May 2017 17:49 > To: Stefano Stabellini > Cc: Paul Durrant ; qemu-de...@nongnu.org; Wei > Liu ; xen-de...@lists.xenproject.org > Subject: Re: QEMU build breakage on ARM against Xen 4.9 caused by > lib

Re: [Xen-devel] QEMU build breakage on ARM against Xen 4.9 caused by libxendevicemodel

On Wed, May 03, 2017 at 05:48:38PM +0100, Anthony PERARD wrote: > On Thu, Apr 20, 2017 at 11:05:33AM -0700, Stefano Stabellini wrote: > > On Thu, 20 Apr 2017, Paul Durrant wrote: > > > I think xencall should be part of the base xen_stable_libs anyway. > > > > Yes, you are right. However I noticed

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

Hello guys, I'm following the OP-TEE discussion. At [1] you can find my patch series for OP-TEE calls handling. It is very old thing, but it worked (and even had nice features like ability to handle domain crash in the middle of OP-TEE session). If you want latest version, just take a look at [2].

Re: [Xen-devel] QEMU build breakage on ARM against Xen 4.9 caused by libxendevicemodel

On Thu, Apr 20, 2017 at 11:05:33AM -0700, Stefano Stabellini wrote: > On Thu, 20 Apr 2017, Paul Durrant wrote: > > I think xencall should be part of the base xen_stable_libs anyway. > > Yes, you are right. However I noticed that -lxencall needs to come after > -lxendevicemodel. So, I'll have to mo

Re: [Xen-devel] Newer Windows in Xen Project osstest test lab

> -Original Message- > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > Sent: 03 May 2017 17:06 > To: Paul Durrant ; 'Jan Beulich' > ; Wei Liu ; xen-devel de...@lists.xenproject.org> > Subject: Newer Windows in Xen Project osstest test lab > > Ian Jackson writes ("RE: [Xen-devel] [x

[Xen-devel] Newer Windows in Xen Project osstest test lab

Ian Jackson writes ("RE: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL"): > Paul Durrant writes ("RE: [Xen-devel] [xen-unstable test] 108068: regressions > - FAIL"): > > Ok, there really should be tests for Windows 10 and/or Server 2016 in > > there. A lot of the newer viridian feat

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

On 03/05/17 12:45, Steven Haigh wrote: > Just wanted to give this a little nudge now people seem to be back on > deck... Glenn, could you please give the attached patch a try? It should be applied on top of the other correction, the old debug patch should not be applied. I have added some debug

Re: [Xen-devel] [PATCH] x86: correct create_bounce_frame

>>> On 02.05.17 at 16:12, wrote: > On 02/05/17 14:22, Jan Beulich wrote: >> @@ -345,15 +344,20 @@ UNLIKELY_START(z, create_bounce_frame_ba >> __UNLIKELY_END(create_bounce_frame_bad_bounce_ip) >> movq %rax,UREGS_rip+8(%rsp) >> ret >> -_ASM_EXTABLE(.Lft2, domain_crash_pa

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

Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface"): > I considered that frontend domain name and surface index is a unique surface > identifier. Like following: > > Surface with index 0 from DomU should be placed at x, y, display 0 etc. Rig

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

On Tue, May 2, 2017 at 5:28 PM, Ian Jackson wrote: > Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV > display device driver interface"): >> On Thu, Apr 13, 2017 at 3:54 PM, Ian Jackson >> wrote: >> > Can you sketch out what the rest of the system does, then ? >> > Presu

[Xen-devel] [linux-3.18 test] 108152: tolerable FAIL - PUSHED

flight 108152 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/108152/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-rumprun-amd64 16 rumprun-demo-xenstorels/xenstorels.repeat fail in 108037 pass in 108152 test-a

Re: [Xen-devel] Hypervisor cpuid time leaf

>>> On 03.05.17 at 16:26, wrote: > Looking at __update_vcpu_system_time(), I am not sure we are reporting > correct values on (PV & !vtsc). I think it should be t->tsc_scale. Indeed. I wouldn't be surprised at all if it was simply assumed by the author to only be used by HVM guests. And the issue

Re: [Xen-devel] Hypervisor cpuid time leaf

>>> On 03.05.17 at 16:06, wrote: > On 03/05/17 14:57, Boris Ostrovsky wrote: >> Is there a reason why we don't document hypervisor time leaf (3, or is >> it 4?) in public/arch-x86/cpuid.h? > > (The leaf with the number 3. The way the documentation refers to leaves > and numeric values is very co

Re: [Xen-devel] [BUG] xl devd segmentation fault on xl block-detach

On Wed, May 03, 2017 at 04:27:41PM +0300, Reinis Martinsons wrote: > On 03.05.2017 13:27, Wei Liu wrote: > libxl: debug: libxl_linux.c:200:libxl__get_hotplug_script_info: num_exec 1, > not running hotplug scripts > libxl: debug: libxl_device.c:1143:device_hotplug: No hotplug script to execute > li

Re: [Xen-devel] Hypervisor cpuid time leaf

On 05/03/2017 10:06 AM, Andrew Cooper wrote: > On 03/05/17 14:57, Boris Ostrovsky wrote: >> Is there a reason why we don't document hypervisor time leaf (3, or is >> it 4?) in public/arch-x86/cpuid.h? > (The leaf with the number 3. The way the documentation refers to leaves > and numeric values is

Re: [Xen-devel] Hypervisor cpuid time leaf

On 03/05/17 14:57, Boris Ostrovsky wrote: > Is there a reason why we don't document hypervisor time leaf (3, or is > it 4?) in public/arch-x86/cpuid.h? (The leaf with the number 3. The way the documentation refers to leaves and numeric values is very counter-intuitive. I half remember a plan to

[Xen-devel] Hypervisor cpuid time leaf

Is there a reason why we don't document hypervisor time leaf (3, or is it 4?) in public/arch-x86/cpuid.h? We have a regression in Linux where there is a window when vcpu_time_info data is not yet available and one possibility is to use this leaf. But I'd like to be sure it is part of a stable ABI.

Re: [Xen-devel] [PATCH 3/7] x86/mm: Further restrict permissions on some virtual mappings

>>> On 03.05.17 at 15:38, wrote: > My method of working out which areas to change were to consider all uses > of __PAGE_HYPERVISOR. I have half a mind to submit a change renaming it > to __PAGE_PGTABLE, as it should only really be used to build > intermediate pagetable entries where we control X/

Re: [Xen-devel] [PATCH v2 2/7] x86/traps: Poison unused stack pointers in the TSS

>>> On 03.05.17 at 15:29, wrote: > This is for additional defence-in-depth following LDT/GDT/IDT corruption. > > It causes attempted control transfers to ring 1 or 2 (via a call gate), or > attempts to use IST 3 through 7 to yield #SS, rather than executing with a > stack starting at the top of v

Re: [Xen-devel] [PATCH 4/7] x86/traps: Rename compat_hypercall() to entry_int82()

On 03/05/17 09:55, Jan Beulich wrote: On 02.05.17 at 20:05, wrote: >> --- a/xen/arch/x86/traps.c >> +++ b/xen/arch/x86/traps.c >> @@ -3872,7 +3872,7 @@ void __init trap_init(void) >> >> /* The 32-on-64 hypercall vector is only accessible from ring 1. */ >> _set_gate(idt_table + HY

Re: [Xen-devel] [PATCH 3/7] x86/mm: Further restrict permissions on some virtual mappings

On 03/05/17 09:49, Jan Beulich wrote: On 02.05.17 at 20:05, wrote: >> As originally reported, the Linear Pagetable slot maps 512GB of ram as RWX, >> where the guest has full read access and a lot of direct or indirect control >> over the written content. It isn't hard for a PV guest to hide

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

On 03/05/17 12:45, Steven Haigh wrote: > Just wanted to give this a little nudge now people seem to be back on > deck... Things seem to be more complicated than I thought. There are clearly paths leading to use-after-free scenarios, e.g. the one of the backtrace below: xen_blkbk_remove() will fr

[Xen-devel] [PATCH v2 2/7] x86/traps: Poison unused stack pointers in the TSS

This is for additional defence-in-depth following LDT/GDT/IDT corruption. It causes attempted control transfers to ring 1 or 2 (via a call gate), or attempts to use IST 3 through 7 to yield #SS, rather than executing with a stack starting at the top of virtual address space. Express the TSS setup

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

Hi Roger, On 15/03/17 16:38, Roger Pau Monn? wrote: On Wed, Mar 15, 2017 at 10:11:35AM -0500, Venu Busireddy wrote: On Wed, Mar 15, 2017 at 12:56:50PM +, Roger Pau Monn? wrote: On Wed, Mar 15, 2017 at 08:42:04AM -0400, Konrad Rzeszutek Wilk wrote: On Wed, Mar 15, 2017 at 12:07:28PM +,

Re: [Xen-devel] [PATCH v3] hvm: fix hypervisor crash in hvm_save_one()

On 03/05/17 13:45, Razvan Cojocaru wrote: > On 05/03/17 15:22, Jan Beulich wrote: >> hvm_save_cpu_ctxt() returns success without writing any data into >> hvm_domain_context_t when all VCPUs are offline. This can then crash >> the hypervisor (with FATAL PAGE FAULT) in hvm_save_one() via the >> "off

Re: [Xen-devel] [PATCH 2/7] x86/traps: Poison unused stack pointers in the TSS

On 03/05/17 09:14, Jan Beulich wrote: On 02.05.17 at 20:05, wrote: >> --- a/xen/arch/x86/cpu/common.c >> +++ b/xen/arch/x86/cpu/common.c >> @@ -645,6 +645,14 @@ void load_system_tables(void) >> tss->ist[IST_DF - 1] = stack_top + IST_DF * PAGE_SIZE; >> tss->ist[IST_NMI - 1] = stack

Re: [Xen-devel] [PATCH v3] hvm: fix hypervisor crash in hvm_save_one()

On 05/03/17 15:22, Jan Beulich wrote: > hvm_save_cpu_ctxt() returns success without writing any data into > hvm_domain_context_t when all VCPUs are offline. This can then crash > the hypervisor (with FATAL PAGE FAULT) in hvm_save_one() via the > "off < (ctxt.cur - sizeof(*desc))" for() test, where

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

Hi Roger, Sorry for the late answer. On 15/03/17 17:00, Roger Pau Monn? wrote: On Wed, Mar 15, 2017 at 11:54:07AM -0500, Venu Busireddy wrote: On Wed, Mar 15, 2017 at 04:38:39PM +, Roger Pau Monn? wrote: On Wed, Mar 15, 2017 at 10:11:35AM -0500, Venu Busireddy wrote: On Wed, Mar 15, 2017

Re: [Xen-devel] [PATCH 5/7] x86/traps: Lift all non-entrypoint logic in entry_int82() up into C

>>> On 03.05.17 at 14:18, wrote: > On 03/05/17 13:02, Jan Beulich wrote: > On 03.05.17 at 13:38, wrote: >>> On 03/05/17 12:26, Wei Liu wrote: On Wed, May 03, 2017 at 03:02:25AM -0600, Jan Beulich wrote: On 02.05.17 at 20:05, wrote: >> --- /dev/null >> +++ b/xen/arch/x86

Re: [Xen-devel] [PATCH 1/7] x86/traps: Drop 32bit fields out of tss_struct

On 03/05/17 09:10, Jan Beulich wrote: On 02.05.17 at 20:05, wrote: >> The backlink field doesn't exist in a 64bit TSS, and union for esp{0..2} is >> of >> no practical use. Specify everything with stdint types, and empty bitfields >> for reserved values. >> >> No functional change. >> >> Si

[Xen-devel] [PATCH v3] hvm: fix hypervisor crash in hvm_save_one()

hvm_save_cpu_ctxt() returns success without writing any data into hvm_domain_context_t when all VCPUs are offline. This can then crash the hypervisor (with FATAL PAGE FAULT) in hvm_save_one() via the "off < (ctxt.cur - sizeof(*desc))" for() test, where ctxt.cur remains 0, causing an underflow which

Re: [Xen-devel] [PATCH 5/7] x86/traps: Lift all non-entrypoint logic in entry_int82() up into C

On 03/05/17 13:02, Jan Beulich wrote: On 03.05.17 at 13:38, wrote: >> On 03/05/17 12:26, Wei Liu wrote: >>> On Wed, May 03, 2017 at 03:02:25AM -0600, Jan Beulich wrote: >>> On 02.05.17 at 20:05, wrote: > --- /dev/null > +++ b/xen/arch/x86/pv/traps.c > @@ -0,0 +1,44 @@ > >

Re: [Xen-devel] [PATCH V2] xen/hvm: fix hypervisor crash with hvm_save_one()

>>> On 03.05.17 at 14:00, wrote: > On 03/05/17 11:44, Razvan Cojocaru wrote: >> On 05/03/17 12:30, Jan Beulich wrote: >> On 03.05.17 at 11:21, wrote: At 10:15 +0100 on 03 May (1493806508), Tim Deegan wrote: > At 00:31 -0600 on 03 May (1493771502), Jan Beulich wrote: >> +else

Re: [Xen-devel] [PATCH 5/7] x86/traps: Lift all non-entrypoint logic in entry_int82() up into C

>>> On 03.05.17 at 13:38, wrote: > On 03/05/17 12:26, Wei Liu wrote: >> On Wed, May 03, 2017 at 03:02:25AM -0600, Jan Beulich wrote: >> On 02.05.17 at 20:05, wrote: --- /dev/null +++ b/xen/arch/x86/pv/traps.c @@ -0,0 +1,44 @@ > +/**

Re: [Xen-devel] [PATCH V2] xen/hvm: fix hypervisor crash with hvm_save_one()

On 03/05/17 11:44, Razvan Cojocaru wrote: > On 05/03/17 12:30, Jan Beulich wrote: > On 03.05.17 at 11:21, wrote: >>> At 10:15 +0100 on 03 May (1493806508), Tim Deegan wrote: At 00:31 -0600 on 03 May (1493771502), Jan Beulich wrote: > +else if ( ctxt.cur > sizeof(*desc) ) >

Re: [Xen-devel] [PATCH 5/7] x86/traps: Lift all non-entrypoint logic in entry_int82() up into C

>>> On 03.05.17 at 13:26, wrote: > On Wed, May 03, 2017 at 03:02:25AM -0600, Jan Beulich wrote: >> >>> On 02.05.17 at 20:05, wrote: >> > --- /dev/null >> > +++ b/xen/arch/x86/pv/traps.c >> > @@ -0,0 +1,44 @@ >> > > +/*** > *

Re: [Xen-devel] [PATCH 5/7] x86/traps: Lift all non-entrypoint logic in entry_int82() up into C

On Wed, May 03, 2017 at 12:38:15PM +0100, Andrew Cooper wrote: > On 03/05/17 12:26, Wei Liu wrote: > > On Wed, May 03, 2017 at 03:02:25AM -0600, Jan Beulich wrote: > > On 02.05.17 at 20:05, wrote: > >>> --- /dev/null > >>> +++ b/xen/arch/x86/pv/traps.c > >>> @@ -0,0 +1,44 @@ > >>> +/**

Re: [Xen-devel] [PATCH 5/7] x86/traps: Lift all non-entrypoint logic in entry_int82() up into C

On 03/05/17 12:26, Wei Liu wrote: > On Wed, May 03, 2017 at 03:02:25AM -0600, Jan Beulich wrote: > On 02.05.17 at 20:05, wrote: >>> --- /dev/null >>> +++ b/xen/arch/x86/pv/traps.c >>> @@ -0,0 +1,44 @@ >>> +/** >>> + *

Re: [Xen-devel] [PATCH 5/7] x86/traps: Lift all non-entrypoint logic in entry_int82() up into C

On Wed, May 03, 2017 at 03:02:25AM -0600, Jan Beulich wrote: > >>> On 02.05.17 at 20:05, wrote: > > --- /dev/null > > +++ b/xen/arch/x86/pv/traps.c > > @@ -0,0 +1,44 @@ > > +/** > > + * arch/x86/pv/traps.c > > + * > > + *

Re: [Xen-devel] [PATCH 3/7] x86/mm: Further restrict permissions on some virtual mappings

On 02/05/17 19:05, Andrew Cooper wrote: > As originally reported, the Linear Pagetable slot maps 512GB of ram as RWX, > where the guest has full read access and a lot of direct or indirect control > over the written content. It isn't hard for a PV guest to hide shellcode > here. > > Therefore, in

Re: [Xen-devel] [PATCH 06/10 v2] xen/arm: vpl011: Add vuart ring-buf and evtchn to xenstore

Hi, >> > It looks like you are reusing the libxl__device_console_add call for the >> > main PV console for the domain, to also add the vuart nodes to xenstore. >> > >> > I don't think it is a good idea to mix the two. I suggest to introduce a >> > new libxl__device call to introduce the vuart node

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

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

Re: [Xen-devel] [PATCH V2 1/2] x86/vm_event: added hvm/vm_event.{h, c}

>>> On 03.05.17 at 12:37, wrote: > On 05/03/17 12:51, Jan Beulich wrote: > On 03.05.17 at 11:10, wrote: >>> --- /dev/null >>> +++ b/xen/arch/x86/hvm/vm_event.c >>> @@ -0,0 +1,101 @@ >>> +/* >>> + * arch/x86/hvm/vm_event.c >>> + * >>> + * HVM vm_event handling routines >>> + * >>> + * Copyrigh

Re: [Xen-devel] [PATCH 03/10 v2] xen/arm: vpl011: Enable pl011 emulation for a guest domain in Xen

>>> On 03.05.17 at 12:22, wrote: > > On 02/05/17 16:23, Julien Grall wrote: >> Hi Bhupinder, >> >> On 02/05/17 16:20, Bhupinder Thakur wrote: >>> Hi Jan, >>> > @@ -631,6 +632,9 @@ int arch_domain_create(struct domain *d, > unsigned int domcr_flags, > if ( (rc = domain_vtimer_ini

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

Just wanted to give this a little nudge now people seem to be back on deck... On 01/05/17 10:55, Glenn Enright wrote: > On 19/04/17 22:09, Juergen Gross wrote: >> On 19/04/17 09:16, Roger Pau Monné wrote: >>> On Wed, Apr 19, 2017 at 06:39:41AM +0200, Juergen Gross wrote: On 19/04/17 03:02, Gl

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

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

Re: [Xen-devel] [PATCH V2] xen/hvm: fix hypervisor crash with hvm_save_one()

On 05/03/17 12:30, Jan Beulich wrote: On 03.05.17 at 11:21, wrote: >> At 10:15 +0100 on 03 May (1493806508), Tim Deegan wrote: >>> At 00:31 -0600 on 03 May (1493771502), Jan Beulich wrote: +else if ( ctxt.cur > sizeof(*desc) ) { uint32_t off; -con

Re: [Xen-devel] [PATCH V2 2/2] x86/vm_event: fix race between __context_switch() and vm_event_resume()

On 05/03/17 13:01, Jan Beulich wrote: On 03.05.17 at 11:10, wrote: >> The introspection agent can reply to a vm_event faster than >> vmx_vmexit_handler() can complete in some cases, where it is then >> not safe for vm_event_set_registers() to modify v->arch.user_regs. >> In the test scenario,

Re: [Xen-devel] [PATCH V2 1/2] x86/vm_event: added hvm/vm_event.{h, c}

On 05/03/17 12:51, Jan Beulich wrote: On 03.05.17 at 11:10, wrote: >> @@ -483,67 +483,7 @@ void hvm_do_resume(struct vcpu *v) >> if ( !handle_hvm_io_completion(v) ) >> return; >> >> -if ( unlikely(v->arch.vm_event) ) >> -{ >> -struct monitor_write_data *w = &v-

Re: [Xen-devel] [PATCH 09/10 v2] xen/arm: vpl011: Add a pl011 uart DT node in the guest device tree

Hi Bhupinder, On 28/04/17 17:01, Bhupinder Thakur wrote: The SBSA uart node format is as specified in Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt and given below: ARM SBSA defined generic UART -- This UART uses a subset of the PL011 registers and conse

Re: [Xen-devel] [BUG] xl devd segmentation fault on xl block-detach

CC Ian On Wed, May 03, 2017 at 03:04:44AM +0300, Reinis Martinsons wrote: > Hi, > > I would like to report a problem with storage driver domain. When detaching > 2 virtual block devices from the same domain provided by the same driver > domain, this generates a segmentation fault in the driver do

Re: [Xen-devel] [PATCH 04/10 v2] xen/arm: vpl011: Add support for vuart in libxl

Hi Bhupinder, On 28/04/17 17:01, Bhupinder Thakur wrote: An option is provided in libxl to enable/disable pl011 vuart while creating a guest domain. Libxl now suppots a generic vuart console and pl011 is a specific type. s/supports/supports/ In future support can be added for multiple vuart

  1   2   >