>>> On 02.05.17 at 18:11, 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
>>> the hypervisor
'commit 1679e0df3df6 ("x86/ioreq server: asynchronously reset
outstanding p2m_ioreq_server entries")' will call
p2m_change_entry_type_global() which set entry.recalc=1. Then
the following get_entry(p2m_ioreq_server) will return
p2m_ram_rw type.
But 'commit 6d774a951696 ("x86/ioreq server: synchrono
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: 52e94ea5de3ed9d7d
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.
>
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
test-amd64-i386
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.
>
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
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
test-amd64-i386
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
=== T
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.
>
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
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
test-
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 faili
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, and
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
test-armhf-armhf-xl
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[] i
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 page
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/include/asm-x86/asm_defns.h | 27 ++-
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 doesn't
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/arch/x86/traps.c| 2 +-
x
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 Cooper
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 have
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: And
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
---
xen/include/asm-x86/asm_defns.h | 13 -
1 file changed, 12 ins
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:
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: 52e94ea5de3ed9d7ddf1b
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 Lutomirski
---
arch/x86/xen/multicalls.c | 26 +-
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
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 (1493263380), Jan Beulich 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.
Moving xen_have_vector_callback definition to enligh
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 mig
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 p
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 == dom_cow" as a condition fo
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
>> ---
>> Possibly we could be e
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 whi
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
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 smaller to
>> > review, a couple of subdirecto
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 ou
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
>>> the
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
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 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 hvm_save_one() via the
>> "off < (c
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 v
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
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 - sizeof(*de
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:
>
> drivers/built-in
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 done in earlier patches
>>> 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 - sizeof(*desc))" for() test, where ctxt
>>> 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 - sizeof(*desc))" for() test, where ctxt
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':
events_base.c:(.te
>>> 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 more rigid and bail right away if ->is_dy
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 = domain_
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
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 )
>> +
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 fail
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.
--- a/xen/arch/x86/mm/p2m.c
+++ b/x
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
__
>>> 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@lists.xen.org
https
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 mig
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 lengt
>>> 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 guest could initiate MMIO
>> re
>>> 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 struct hvm_save_descriptor *desc
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 be
> found?
>
> T
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 whi
>>> 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 reflected in the early
>> address r
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.
__
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
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 different control protocol to your
>
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
> +++ b/xen/common/hvm/save.c
> @@ -113,7 +113,7 @@ int hvm
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 t
> -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
> Subject: Re: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL
>
> >>> On 02.05.17
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 o
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 @@ int hvm_save_one(struct domain *d, uint16_t typecode,
>>
>>> 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 agree with the first sentenc
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 list
>>> 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 typecode,
>>> uint16_t instance,
>>> const stru
> -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: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL
>
> Paul Durrant writes ("RE: [Xen-devel] [xen-u
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
> >
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
>
> http://logs.test-lab.xenproject.org/osstest/logs/108068/test-amd64-
> -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: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL
>
> Paul Durrant writes ("RE: [Xen-devel] [xen-u
On 02/05/17 14:48, Jan Beulich wrote:
On 02.05.17 at 15:25, wrote:
>> hvm_save_cpu_ctxt() does a memset(&ctxt, 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))"
On 05/02/17 16:48, Jan Beulich wrote:
On 02.05.17 at 15:25, wrote:
>> hvm_save_cpu_ctxt() does a memset(&ctxt, 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))"
>>> On 02.05.17 at 15:25, wrote:
> hvm_save_cpu_ctxt() does a memset(&ctxt, 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 practic
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 25942a40262083042798b
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 now)
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
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(&ctxt, 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
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
Hi,
At 16:25 +0300 on 02 May (1493742339), Razvan Cojocaru wrote:
> hvm_save_cpu_ctxt() does a memset(&ctxt, 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() tes
> -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] [xen-unstable test] 108068: regressions - FAIL
>
> >>> On 02.05.17 at 14:45,
On 02/05/17 14:25, Razvan Cojocaru wrote:
> hvm_save_cpu_ctxt() does a memset(&ctxt, 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.c
>>> 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 been
asked a while ago alread
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
> >
> > 2017-05-01 13:18:52 Z execut
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 executing ssh ... root@172.16.144.
hvm_save_cpu_ctxt() does a memset(&ctxt, 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:
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 ex
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 instead
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 w
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 w
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 synch
1 - 100 of 142 matches
Mail list logo
