[Xen-devel] [qemu-mainline bisection] complete build-armhf-xsm

branch xen-unstable xenbranch xen-unstable job build-armhf-xsm testid xen-build Tree: qemuu git://git.qemu.org/qemu.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: qemuu git://git.qemu.org/qemu.git Bug introduced:

Re: [Xen-devel] [PATCH] xen: Move xen_have_vector_callback definition to enlighten.c

On 02/05/17 19:23, Boris Ostrovsky wrote: > Commit 84d582d236dc ("xen: Revert commits da72ff5bfcb0 and > 72a9b186292d") defined xen_have_vector_callback in enlighten_hvm.c. > Since guest-type-neutral code refers to this variable this causes > build failures when CONFIG_XEN_PVHVM is not defined. >

[Xen-devel] [xen-4.6-testing test] 108138: regressions - FAIL

flight 108138 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/108138/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-i386-pvgrub 9 debian-di-installfail REGR. vs. 107356

Re: [Xen-devel] [PATCH] xen: Move xen_have_vector_callback definition to enlighten.c

On 02/05/17 19:23, Boris Ostrovsky wrote: > Commit 84d582d236dc ("xen: Revert commits da72ff5bfcb0 and > 72a9b186292d") defined xen_have_vector_callback in enlighten_hvm.c. > Since guest-type-neutral code refers to this variable this causes > build failures when CONFIG_XEN_PVHVM is not defined. >

[Xen-devel] [PATCH] 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] [xen-4.8-testing test] 108136: regressions - FAIL

flight 108136 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/108136/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-amd64-pvgrub 9 debian-di-install fail REGR. vs. 107370

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

Hi, This series seems to have some coding style problems. See output below for more information: Subject: [Qemu-devel] [PATCH RFC] xen/mapcache: store dma information in revmapcache entries for debugging Message-id: alpine.DEB.2.10.1705021646310.8859@sstabellini-ThinkPad-X260 Type: series ===

Re: [Xen-devel] [PATCH] xen: Move xen_have_vector_callback definition to enlighten.c

On 05/02/17 10:23, Boris Ostrovsky wrote: > Commit 84d582d236dc ("xen: Revert commits da72ff5bfcb0 and > 72a9b186292d") defined xen_have_vector_callback in enlighten_hvm.c. > Since guest-type-neutral code refers to this variable this causes > build failures when CONFIG_XEN_PVHVM is not defined. >

[Xen-devel] [PATCH RFC] 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] [xen-4.7-testing test] 108137: regressions - FAIL

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

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

flight 108127 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/108127/ 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] [PATCH v8 1/5] x86: add simple udelay calibration

On 03/21/2017 04:01 AM, Lu Baolu wrote: > Add a simple udelay calibration in x86 architecture-specific > boot-time initializations. This will get a workable estimate > for loops_per_jiffy. Hence, udelay() could be used after this > initialization. This breaks Xen PV guests since at this point,

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

flight 108124 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/108124/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-xsm 11 guest-start fail REGR. vs. 59254

Re: [Xen-devel] [PATCH] x86/xen: Improve failed hypercall debugging

On 05/02/2017 01:59 PM, Andy Lutomirski wrote: > When fiddling with xen_exit_mmap(), I noticed that failed multicall > debugging doesn't work if the multicall is just one call. Fix it. That wouldn't be a multicall though, we'll end up making the desired hypercall directly. Besides, b->debug[]

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

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, increase defence in depth by auditing our current

[Xen-devel] [PATCH 6/7] x86/asm: Fold LOAD_C_CLOBBERED into RESTORE_ALL

With its sole other user removed, fold LOAD_C_CLOBBERED into RESTORE_ALL to reduce the cognitive load of trying to work out which registers get modified. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich ---

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

This follows the Linux example of naming the entry point by how it is arrived at, rather than its purpose. Doing so highlights that the SAVE_VOLATILE instantiation sets up the wrong entry_vector on the stack (although this is benign as we never sysret to a 32bit PV guest, and the iret path

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

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. Signed-off-by: Andrew Cooper --- CC: Jan Beulich

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

This is more readable, maintainable, and livepatchable. This involves declaring check_for_unexpected_msi(), untrusted_msi and pv_hypercall() suitably for use by C. While making these changes, untrusted_msi is switched over to being a C99 bool. No behavioural change. Signed-off-by: Andrew

[Xen-devel] [PATCH 0/7] XSAs 213-315 followups

Various improvements based on observations while investigating and fixing the aformentioned XSAs. All are candidate patches for 4.9 at this point, with patches 2, 3 and 7 being the important ones from an attack-surface-mitigation point of view. This is the subset of my intented series, but I

[Xen-devel] [PATCH 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[0], rather than executing with a stack starting at the top of virtual address space. Signed-off-by:

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

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

Hi all, A quick reminder, the Community Call will be tomorrow (Wednesday 3rd May) at 5PM BST. For joining the call, please use either: Call+44 1223 406065 (Local dial in) and enter the access code below followed by # key. Participant code: 4915191 Mobile Auto Dial: VoIP:

[Xen-devel] [qemu-mainline bisection] complete build-armhf

branch xen-unstable xenbranch xen-unstable job build-armhf testid xen-build Tree: qemuu git://git.qemu.org/qemu.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: qemuu git://git.qemu.org/qemu.git Bug introduced:

[Xen-devel] [PATCH] x86/xen: Improve failed hypercall debugging

When fiddling with xen_exit_mmap(), I noticed that failed multicall debugging doesn't work if the multicall is just one call. Fix it. Cc: Juergen Gross Cc: Konrad Rzeszutek Wilk Cc: Boris Ostrovsky Signed-off-by: Andy

Re: [Xen-devel] Security response; public holidays

George Dunlap writes ("Re: Security response; public holidays"): > Some holidays will be fixed dates, while others (like Easter and > American Thanksgiving) will change every year. For the ones that > change, we need a mechanism for refreshing them every year. I suggest we set a reminder to send

Re: [Xen-devel] [PATCH v2] x86/mm: also flush TLB when putting writable foreign page reference

On 02/05/17 10:43, Tim Deegan wrote: > At 02:50 -0600 on 02 May (1493693403), Jan Beulich wrote: > On 02.05.17 at 10:32, wrote: >>> At 04:52 -0600 on 28 Apr (1493355160), Jan Beulich wrote: >>> On 27.04.17 at 11:51, wrote: > At 03:23 -0600 on 27 Apr

[Xen-devel] [PATCH] xen: Move xen_have_vector_callback definition to enlighten.c

Commit 84d582d236dc ("xen: Revert commits da72ff5bfcb0 and 72a9b186292d") defined xen_have_vector_callback in enlighten_hvm.c. Since guest-type-neutral code refers to this variable this causes build failures when CONFIG_XEN_PVHVM is not defined. Moving xen_have_vector_callback definition to

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

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

Re: [Xen-devel] Security response; public holidays

On 02/05/17 15:09, Ian Jackson wrote: > We selected today as the release date for XSA-213 to 215. But if we > had thought it through properly, with the right information, I think > we could have chosen a different date, because of the public holidays > in many countries around now. > > It would

Re: [Xen-devel] [PATCH] x86/mm: silence a pointless warning

On 02/05/17 16:15, Jan Beulich wrote: > get_page() logs a message when it fails (dom_cow is never dying or > paging_mode_external()), so better avoid the call when it's pointless > to do anyway. > > Signed-off-by: Jan Beulich The other option would be to add "domain ==

Re: [Xen-devel] [PATCH] x86/mm: silence a pointless warning

On 02/05/17 16:31, Jan Beulich wrote: On 02.05.17 at 17:15, wrote: >> get_page() logs a message when it fails (dom_cow is never dying or >> paging_mode_external()), so better avoid the call when it's pointless >> to do anyway. >> >> Signed-off-by: Jan Beulich

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

flight 108118 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/108118/ 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. 107606 Tests

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

flight 108125 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/108125/ 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] [Qemu-devel] [PATCH v5 06/10] qobject: Use simpler QDict/QList scalar insertion macros

Stefan Hajnoczi writes: > On Fri, Apr 28, 2017 at 10:33:36AM +0200, Markus Armbruster wrote: >> Eric Blake writes: >> >> > We now have macros in place to make it less verbose to add a scalar >> > to QDict and QList, so use them. To make this patch

[Xen-devel] [OSSTEST PATCH] Debian grub2 config: set TERMINAL to 'serial console'

It is usually useful to enable the BIOS option `continue redirection after boot', where provided. This shows messages from pxelinux etc. But this can breaks serial access for grub, depending on the host. (This is true on the noblings, for example.) Using TERMINAL='serial console' provides the

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

On 05/02/2017 07:11 PM, Andrew Cooper wrote: > On 02/05/17 17:02, Tim Deegan wrote: >> At 18:21 +0300 on 02 May (1493749307), Razvan Cojocaru 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 >>>

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

flight 108121 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/108121/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt5 libvirt-buildfail REGR. vs. 107640 build-amd64-libvirt

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

On 02/05/17 17:02, Tim Deegan wrote: > At 18:21 +0300 on 02 May (1493749307), Razvan Cojocaru 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

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

On 05/02/2017 06:41 PM, Jan Beulich wrote: On 02.05.17 at 17:21, 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

[Xen-devel] [ovmf baseline-only test] 71247: all pass

This run is configured for baseline tests only. flight 71247 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71247/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 91cdd20f70c5bc739ef45b13e08ae662fbbc55cf baseline

Re: [Xen-devel] [PATCH 01/10 v2] xen/arm: vpl011: Add pl011 uart emulation in Xen

Hi Bhupinder, On 28/04/17 17:01, Bhupinder Thakur wrote: Add emulation code to emulate read/write access to pl011 registers and pl011 interrupts: - Emulate DR read/write by reading and writing from/to the IN and OUT ring buffers and raising an event to the backend when there is

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

At 18:21 +0300 on 02 May (1493749307), Razvan Cojocaru 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 -

Re: [Xen-devel] linux-next: Tree for May 2 (xen: events_base.c)

On 05/02/2017 11:34 AM, Randy Dunlap wrote: > On 05/01/17 23:47, Stephen Rothwell wrote: >> Hi all, >> >> Please do not add any v4.13 destined material in your linux-next >> included branches until after v4.12-rc1 has been released. >> >> Changes since 20170501: >> > on x86_64: > >

Re: [Xen-devel] [Qemu-devel] [PATCH v5 06/10] qobject: Use simpler QDict/QList scalar insertion macros

On Fri, Apr 28, 2017 at 10:33:36AM +0200, Markus Armbruster wrote: > Eric Blake writes: > > > We now have macros in place to make it less verbose to add a scalar > > to QDict and QList, so use them. To make this patch smaller to > > review, a couple of subdirectories were

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

>>> On 02.05.17 at 17:21, 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 -

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

>>> On 02.05.17 at 17:21, 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 -

Re: [Xen-devel] linux-next: Tree for May 2 (xen: events_base.c)

On 05/01/17 23:47, Stephen Rothwell wrote: > Hi all, > > Please do not add any v4.13 destined material in your linux-next > included branches until after v4.12-rc1 has been released. > > Changes since 20170501: > on x86_64: drivers/built-in.o: In function `set_affinity_irq':

Re: [Xen-devel] [PATCH] x86/mm: silence a pointless warning

>>> On 02.05.17 at 17:15, wrote: > get_page() logs a message when it fails (dom_cow is never dying or > paging_mode_external()), so better avoid the call when it's pointless > to do anyway. > > Signed-off-by: Jan Beulich > --- > Possibly we could be even

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

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_init(d, config)) != 0 ) goto fail; +if ( domcr_flags & DOMCRF_vuart ) +if ( (rc =

[Xen-devel] [PATCH V2] xen/hvm: fix hypervisor crash with 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

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

Hi Jan, >> @@ -631,6 +632,9 @@ int arch_domain_create(struct domain *d, unsigned int >> domcr_flags, >> if ( (rc = domain_vtimer_init(d, config)) != 0 ) >> goto fail; >> >> +if ( domcr_flags & DOMCRF_vuart ) >> +if ( (rc = domain_vpl011_init(d, config)) != 0 ) >> +

Re: [Xen-devel] [RFC PATCH 4/4] arm/mem_access: Add software guest-page-table walk

Hi Sergej, On 30/04/17 20:48, Sergej Proskurin wrote: The function p2m_mem_access_check_and_get_page in mem_access.c translates a gva to an ipa by means of the hardware functionality implemented in the function gva_to_ipa. If mem_access is active, hardware-based gva to ipa translation might

[Xen-devel] [PATCH] x86/mm: silence a pointless warning

get_page() logs a message when it fails (dom_cow is never dying or paging_mode_external()), so better avoid the call when it's pointless to do anyway. Signed-off-by: Jan Beulich --- Possibly we could be even more rigid and bail right away if ->is_dying is set. ---

Re: [Xen-devel] [PATCH v3 0/9] Memory scrubbing from idle loop

On 05/02/2017 10:58 AM, Jan Beulich wrote: On 02.05.17 at 16:46, wrote: >> Ping? > I has made it to near the top of my to-be-reviewed list, so hopefully > soon. It's post-4.9 stuff only anyway, so not really needing quick > turnaround. Thanks. -boris

Re: [Xen-devel] [PATCH v3 0/9] Memory scrubbing from idle loop

>>> On 02.05.17 at 16:46, wrote: > Ping? I has made it to near the top of my to-be-reviewed list, so hopefully soon. It's post-4.9 stuff only anyway, so not really needing quick turnaround. Jan ___ Xen-devel mailing list

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

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

Re: [Xen-devel] [PATCH v3 0/9] Memory scrubbing from idle loop

Ping? On 04/14/2017 11:37 AM, Boris Ostrovsky wrote: > When a domain is destroyed the hypervisor must scrub domain's pages before > giving them to another guest in order to prevent leaking the deceased > guest's data. Currently this is done during guest's destruction, possibly > causing very

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

>>> 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 else any PV

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

>>> On 02.05.17 at 16:13, wrote: > So you would prefer something like this? Not exactly: > --- a/xen/common/hvm/save.c > +++ b/xen/common/hvm/save.c > @@ -113,6 +113,10 @@ int hvm_save_one(struct domain *d, uint16_t > typecode, uint16_t instance, > const

Re: [Xen-devel] Stale Documentation

On Fri, Apr 28, 2017 at 10:20 PM, Gary R Hook wrote: > I'm reading through the page at https://wiki.xen.org/wiki/Linux_PVH, > because, well, it > claims that AMD hardware isn't supported. That bothers me. > > The date on the page is December 2014. Is there nothing more current to

Re: [Xen-devel] [libvirt test] 107696: regressions - FAIL

On 05/02/2017 04:28 AM, Ian Jackson wrote: Jim Fehlig writes ("Re: [Xen-devel] [libvirt test] 107696: regressions - FAIL"): On 04/26/2017 02:34 PM, osstest service owner wrote: flight 107696 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/107696/ Regressions :-( Tests

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: >> Commit d9b7ef209a7 ("x86: drop failsafe callback invocation from >> assembly") didn't go quite far enough with the cleanup it did: The >> changed maximum frame size should also have been

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 features only apply to those OS. I'll look into this. Ian.

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

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 else any PV guest could initiate MMIO > reads with side effects. > > Clean up all

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"): > On Thu, Apr 13, 2017 at 3:54 PM, Ian Jackson > wrote: > > Can you sketch out what the rest of the system does, then ? > > Presumably there has to be a

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

On 02/05/17 15:13, Razvan Cojocaru wrote: > On 05/02/17 17:09, Jan Beulich wrote: > On 02.05.17 at 15:54, wrote: >>> On 05/02/17 16:48, Jan Beulich wrote: >>> On 02.05.17 at 15:25, wrote: > --- a/xen/common/hvm/save.c > +++

Re: [Xen-devel] Stale Documentation

On 05/02/2017 08:06 AM, Wei Liu wrote: > CC Roger and Boris > > On Fri, Apr 28, 2017 at 04:20:12PM -0500, Gary R Hook wrote: >> I'm reading through the page at https://wiki.xen.org/wiki/Linux_PVH, >> because, well, it >> claims that AMD hardware isn't supported. That bothers me. >> >> The date on

Re: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan > Beulich > Sent: 02 May 2017 15:11 > To: Paul Durrant > Cc: Ian Jackson ; Wei Liu ; > xen-devel

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

On 02/05/17 14:22, Jan Beulich wrote: > Commit d9b7ef209a7 ("x86: drop failsafe callback invocation from > assembly") didn't go quite far enough with the cleanup it did: The > changed maximum frame size should also have been reflected in the early > address range check (which has now been pointed

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

On 05/02/17 17:09, Jan Beulich wrote: On 02.05.17 at 15:54, wrote: >> On 05/02/17 16:48, Jan Beulich wrote: >> On 02.05.17 at 15:25, wrote: --- a/xen/common/hvm/save.c +++ b/xen/common/hvm/save.c @@ -113,7 +113,7 @@

Re: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL

>>> On 02.05.17 at 15:58, wrote: > IMO testing OS that are so massively out of date is probably not worthwhile. > If there is any real problem then I'd expect it to manifest across multiple > versions of Windows and so other tests should catch such an issue. While I

[Xen-devel] Security response; public holidays

We selected today as the release date for XSA-213 to 215. But if we had thought it through properly, with the right information, I think we could have chosen a different date, because of the public holidays in many countries around now. It would perhaps be possible to find a holiday calendar

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

>>> On 02.05.17 at 15:54, wrote: > On 05/02/17 16:48, Jan Beulich wrote: > On 02.05.17 at 15:25, wrote: >>> --- a/xen/common/hvm/save.c >>> +++ b/xen/common/hvm/save.c >>> @@ -113,7 +113,7 @@ int hvm_save_one(struct domain *d, uint16_t

Re: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL

> -Original Message- > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > Sent: 02 May 2017 15:04 > To: Paul Durrant > Cc: 'Jan Beulich' ; Wei Liu ; xen- > devel > Subject: RE:

Re: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL

On Tue, May 02, 2017 at 03:04:27PM +0100, Ian Jackson wrote: > Paul Durrant writes ("RE: [Xen-devel] [xen-unstable test] 108068: regressions > - FAIL"): > > It's very hard to say. There's nothing particularly conclusive in the logs. > > QEMU has definitely requested a reset as can be seen in >

Re: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL

Paul Durrant writes ("RE: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL"): > It's very hard to say. There's nothing particularly conclusive in the logs. > QEMU has definitely requested a reset as can be seen in > >

Re: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL

> -Original Message- > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > Sent: 02 May 2017 14:44 > To: Paul Durrant > Cc: 'Jan Beulich' ; Wei Liu ; xen- > devel > Subject: RE:

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

On 02/05/17 14:48, Jan Beulich wrote: On 02.05.17 at 15:25, wrote: >> hvm_save_cpu_ctxt() does a memset(, 0, sizeof(ctxt)), which >> can lead to ctxt.cur being 0. This can then crash the hypervisor >> (with FATAL PAGE FAULT) in hvm_save_one() via the >> "off <

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

On 05/02/17 16:48, Jan Beulich wrote: On 02.05.17 at 15:25, wrote: >> hvm_save_cpu_ctxt() does a memset(, 0, sizeof(ctxt)), which >> can lead to ctxt.cur being 0. This can then crash the hypervisor >> (with FATAL PAGE FAULT) in hvm_save_one() via the >> "off <

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

>>> On 02.05.17 at 15:25, wrote: > hvm_save_cpu_ctxt() does a memset(, 0, sizeof(ctxt)), which > can lead to ctxt.cur being 0. This can then crash the hypervisor > (with FATAL PAGE FAULT) in hvm_save_one() via the > "off < (ctxt.cur - sizeof(*desc))" for() test. This

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

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

Re: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL

On 02/05/17 14:42, Ian Jackson wrote: > Andrew Cooper writes ("Re: [Xen-devel] [xen-unstable test] 108068: > regressions - FAIL"): >> This is known, and has definitely been discussed before on xen-devel >> before (although it involved IanC last time he looked at these tests, so >> a while ago

Re: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL

Paul Durrant writes ("RE: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL"): > In my experience Windows is usually consistent in its behaviour on power or > sleep events so it's unlikely that it would reboot sometime and not others. > BTW, is this test really testing XP SP3? It's been

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

On 05/02/17 16:41, Tim Deegan wrote: > Hi, > > At 16:25 +0300 on 02 May (1493742339), Razvan Cojocaru wrote: >> hvm_save_cpu_ctxt() does a memset(, 0, sizeof(ctxt)), which >> can lead to ctxt.cur being 0. This can then crash the hypervisor >> (with FATAL PAGE FAULT) in hvm_save_one() via the >>

Re: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL

Andrew Cooper writes ("Re: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL"): > This is known, and has definitely been discussed before on xen-devel > before (although it involved IanC last time he looked at these tests, so > a while ago now). > > In an APCI view of the world, the two

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

Hi, At 16:25 +0300 on 02 May (1493742339), Razvan Cojocaru wrote: > hvm_save_cpu_ctxt() does a memset(, 0, sizeof(ctxt)), which > can lead to ctxt.cur being 0. This can then crash the hypervisor > (with FATAL PAGE FAULT) in hvm_save_one() via the > "off < (ctxt.cur - sizeof(*desc))" for() test.

Re: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 02 May 2017 14:33 > To: Paul Durrant ; Ian Jackson > > Cc: Wei Liu ; xen-devel de...@lists.xenproject.org> > Subject: Re: [Xen-devel]

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

On 02/05/17 14:25, Razvan Cojocaru wrote: > hvm_save_cpu_ctxt() does a memset(, 0, sizeof(ctxt)), which > can lead to ctxt.cur being 0. Unfortunately, different objects both named ctxt. > This can then crash the hypervisor > (with FATAL PAGE FAULT) in hvm_save_one() via the > "off < (ctxt.cur -

Re: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL

>>> On 02.05.17 at 14:45, wrote: > Is it possible that something has changed which means that Windows > (sometimes?) doesn't respond to an ACPI power button event by shutting > down, but by rebooting ? I can't exclude it, and I vaguely recall the same question having

Re: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL

On Tue, May 02, 2017 at 01:45:28PM +0100, Ian Jackson wrote: > Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 108068: regressions > - FAIL"): > > On 01.05.17 at 20:49, wrote: > > This has been recurring for the last few flights, but I wonder whether > > >

Re: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL

On 02/05/17 13:45, Ian Jackson wrote: > Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 108068: regressions > - FAIL"): >> On 01.05.17 at 20:49, wrote: >> This has been recurring for the last few flights, but I wonder whether >> >> 2017-05-01 13:18:52 Z

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

hvm_save_cpu_ctxt() does a memset(, 0, sizeof(ctxt)), which can lead to ctxt.cur being 0. This can then crash the hypervisor (with FATAL PAGE FAULT) in hvm_save_one() via the "off < (ctxt.cur - sizeof(*desc))" for() test. This has happened in practice with a Linux VM queried around shutdown:

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

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 else any PV guest could initiate MMIO reads with side effects. Clean up all four macros at once: - all arguments evaluated

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

Commit d9b7ef209a7 ("x86: drop failsafe callback invocation from assembly") didn't go quite far enough with the cleanup it did: The changed maximum frame size should also have been reflected in the early address range check (which has now been pointed out to have been wrong anyway, using 60

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

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

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

On 27/04/17 18:26, Volodymyr Babchuk wrote: Hi Julien, Hi Volodymyr, I'm back with profiler results. Oh, yes. Sorry I forgot this thread. Continuing on that, you said that "Now profiler shows that hypervisor spends time in spinlocks and p2m code." Could you expand here? How the EL0 app

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

Hi, On 27/04/17 16:25, George Dunlap wrote: A couple of notes: - I think these things will inevitably end up being somewhat complicated. We should always strive for simplicity and flexibility, but the main thing is that we should use the right tool for the right job: This is for handling

Re: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL

Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL"): > On 01.05.17 at 20:49, wrote: > This has been recurring for the last few flights, but I wonder whether > > 2017-05-01 13:18:52 Z executing ssh ... root@172.16.144.40 readlink >

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

On 26/04/17 22:44, Volodymyr Babchuk wrote: Hi Julien, Hi Volodymyr, On 25 April 2017 at 14:43, Julien Grall wrote: We will also need another type of application: one which is periodically called by XEN itself, not actually servicing any domain request. This is

  1   2   >