flight 156015 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156015/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
flight 156012 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156012/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
flight 156011 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156011/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
flight 156010 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156010/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 29d14d3a30fdfbe017d39b759423832054280f10
baseline version:
ovmf 93edd1887e34c3959ce92
flight 155973 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155973/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 155960
test-amd64-amd64-xl-qemuu-ws16-amd64
flight 156008 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156008/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
flight 155998 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155998/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 93edd1887e34c3959ce927da1a22e8c54ce18a83
baseline version:
ovmf 92e9c44f205a876556abe
flight 155994 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155994/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
branch xen-unstable
xenbranch xen-unstable
job build-arm64
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem ch
On 10/19/20 6:43 PM, Rich Persaud wrote:
> On Oct 19, 2020, at 11:52, Håkon Alstadheim wrote:
>>
>> Den 19.10.2020 17:16, skrev Håkon Alstadheim:
>>> Den 19.10.2020 13:00, skrev George Dunlap:
> On Jan 31, 2020, at 3:33 PM, Wei Liu wrote:
>
> On Fri, Jan 17, 2020 at 02:13:04PM -05
> Does booting with sched=credit alter the symptoms?
Indeed I've tried this, the result is an observable delay, unusable
performance, credit2 seems to be the only usable scheduler, I'm certain it has
something to do with SMT being disabled, resulting in 8 cores instead of the
expected 16 thread
On Mon, Oct 19, 2020 at 12:42:15PM -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH wrote:
> >
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > > From: Tom Rix
> > >
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am won
On Oct 19, 2020, at 11:52, Håkon Alstadheim wrote:
>
>
> Den 19.10.2020 17:16, skrev Håkon Alstadheim:
>> Den 19.10.2020 13:00, skrev George Dunlap:
>>>
On Jan 31, 2020, at 3:33 PM, Wei Liu wrote:
On Fri, Jan 17, 2020 at 02:13:04PM -0500, Rich Persaud wrote:
> On Aug 26, 2
branch xen-unstable
xenbranch xen-unstable
job build-arm64-xsm
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced proble
IRQs can be shared, so uniquely labeling doesn't always work. You run
into issues if you have domA_t allowed access to device_A_t and domB_t
to device_B_t. The shared IRQ can only be labeled one of
device_A_t or device_B_t, and assignment of the second device fails
since domA_t doesn't have permi
flight 155981 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155981/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
The device model state saved by QMP xen-save-devices-state doesn't
include the vmdesc json. When restoring an HVM, xen-load-devices-state
always triggers "Expected vmdescription section, but got 0". This is
not a problem when restore comes from a file. However, when QEMU runs
in a linux stubdom
From: Tom Rix
A break is not needed if it is preceded by a goto
Signed-off-by: Tom Rix
---
drivers/block/xen-blkback/blkback.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/block/xen-blkback/blkback.c
b/drivers/block/xen-blkback/blkback.c
index adfc9352351d..f769fbd1b4c4 100644
-
On Mon, 5 Oct 2020, Volodymyr Babchuk wrote:
> OP-TEE mediator tracks cookie value for a last buffer which
> was requested by OP-TEE. This tracked value serves one important
> purpose: if OP-TEE wants to request another buffer, we know
> that it finished importing previous one and we can free page
On Sat, Oct 17, 2020 at 10:43 PM Greg KH wrote:
>
> On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > From: Tom Rix
> >
> > This is a upcoming change to clean up a new warning treewide.
> > I am wondering if the change could be one mega patch (see below) or
> > normal patch per
On Fri, 16 Oct 2020, Artem Mygaiev wrote:
> -Original Message-
> From: Julien Grall
> Sent: пятница, 16 октября 2020 г. 13:24
> To: Anastasiia Lukianenko ;
> jbeul...@suse.com; george.dun...@citrix.com
> Cc: Artem Mygaiev ; vicooo...@gmail.com;
> xen-devel@lists.xenproject.org; committ.
On Fri, 16 Oct 2020, Bertrand Marquis wrote:
> If for some reason the hardware reset is not working, print a message to
> the user every 5 seconds to warn him that the system did not reset
> properly and Xen is still looping.
>
> The message is printed infinitely so that someone connecting to a se
flight 155976 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155976/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 92e9c44f205a876556abe1a1addea5c40e4f3ccf
baseline version:
ovmf 709b163940c55604b9834
On 19/10/2020 10:09, Jan Beulich wrote:
> On 16.10.2020 17:38, Andrew Cooper wrote:
>> On 15/10/2020 09:01, Jan Beulich wrote:
>>> On 14.10.2020 15:57, Andrew Cooper wrote:
On 13/10/2020 16:58, Jan Beulich wrote:
> On 09.10.2020 17:09, Andrew Cooper wrote:
>> At the time of XSA-170, th
On 19/10/2020 16:47, Jan Beulich wrote:
> On 19.10.2020 17:22, Andrew Cooper wrote:
>> On 19/10/2020 16:02, Jan Beulich wrote:
>>> On 19.10.2020 16:30, Andrew Cooper wrote:
On 19/10/2020 15:21, Jan Beulich wrote:
> On 19.10.2020 16:10, Andrew Cooper wrote:
>> On 19/10/2020 14:40, Jan B
Den 19.10.2020 17:16, skrev Håkon Alstadheim:
Den 19.10.2020 13:00, skrev George Dunlap:
On Jan 31, 2020, at 3:33 PM, Wei Liu wrote:
On Fri, Jan 17, 2020 at 02:13:04PM -0500, Rich Persaud wrote:
On Aug 26, 2019, at 17:08, Pasi Kärkkäinen wrote:
Hi,
On Mon, Oct 08, 2018 at 10:32:45AM -
On 19.10.2020 17:22, Andrew Cooper wrote:
> On 19/10/2020 16:02, Jan Beulich wrote:
>> On 19.10.2020 16:30, Andrew Cooper wrote:
>>> On 19/10/2020 15:21, Jan Beulich wrote:
On 19.10.2020 16:10, Andrew Cooper wrote:
> On 19/10/2020 14:40, Jan Beulich wrote:
>> Of the state saved by the
On Mon, Oct 19, 2020 at 11:45:05AM +0200, Christian König wrote:
> Hi Thomas,
>
> [SNIP]
> > > > +int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map
> > > > *map)
> > > > +{
> > > > + struct ttm_resource *mem = &bo->mem;
> > > > + int ret;
> > > > +
> > > > + ret = ttm_m
flight 155979 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155979/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
On 19.10.2020 17:26, Jason Andryuk wrote:
> On Mon, Oct 19, 2020 at 3:38 AM Jan Beulich wrote:
>> On 16.10.2020 18:28, Jason Andryuk wrote:
>>> Looks like we can pass XC_DOM_PV_CONTAINER/XC_DOM_HVM_CONTAINER down
>>> into elf_xen_parse(). Then we would just validate phys_entry for HVM
>>> and vir
On Mon, Oct 19, 2020 at 3:38 AM Jan Beulich wrote:
>
> On 16.10.2020 18:28, Jason Andryuk wrote:
> > Looks like we can pass XC_DOM_PV_CONTAINER/XC_DOM_HVM_CONTAINER down
> > into elf_xen_parse(). Then we would just validate phys_entry for HVM
> > and virt_entry for PV. Does that sound reasonable
On 08.10.2020 20:57, Paul Durrant wrote:
> @@ -1671,6 +1672,118 @@ int continue_hypercall_on_cpu(
> return 0;
> }
>
> +static int save_shared_info(struct domain *d, struct domain_ctxt_state *c,
> +bool dry_run)
> +{
> +#ifdef CONFIG_COMPAT
> +struct domain_co
On 19/10/2020 16:02, Jan Beulich wrote:
> On 19.10.2020 16:30, Andrew Cooper wrote:
>> On 19/10/2020 15:21, Jan Beulich wrote:
>>> On 19.10.2020 16:10, Andrew Cooper wrote:
On 19/10/2020 14:40, Jan Beulich wrote:
> Of the state saved by the insn and reloaded by the corresponding VMLOAD
>>>
Den 19.10.2020 13:00, skrev George Dunlap:
On Jan 31, 2020, at 3:33 PM, Wei Liu wrote:
On Fri, Jan 17, 2020 at 02:13:04PM -0500, Rich Persaud wrote:
On Aug 26, 2019, at 17:08, Pasi Kärkkäinen wrote:
Hi,
On Mon, Oct 08, 2018 at 10:32:45AM -0400, Boris Ostrovsky wrote:
On 10/3/18 11:51 A
On 19.10.2020 16:30, Jan Beulich wrote:
> On 08.10.2020 20:57, Paul Durrant wrote:
>> +static int dry_run_end(void *priv, size_t len)
>> +{
>> +struct domctl_context *c = priv;
>> +
>> +ASSERT(IS_ALIGNED(c->len, DOMAIN_CONTEXT_RECORD_ALIGN));
>> +
>> +return 0;
>> +}
>> +
>> +static str
On 19.10.2020 16:30, Andrew Cooper wrote:
> On 19/10/2020 15:21, Jan Beulich wrote:
>> On 19.10.2020 16:10, Andrew Cooper wrote:
>>> On 19/10/2020 14:40, Jan Beulich wrote:
Of the state saved by the insn and reloaded by the corresponding VMLOAD
- TR, syscall, and sysenter state are invari
On 19/10/2020 15:21, Jan Beulich wrote:
> On 19.10.2020 16:10, Andrew Cooper wrote:
>> On 19/10/2020 14:40, Jan Beulich wrote:
>>> Of the state saved by the insn and reloaded by the corresponding VMLOAD
>>> - TR, syscall, and sysenter state are invariant while having Xen's state
>>> loaded,
>>> -
On 08.10.2020 20:57, Paul Durrant wrote:
> +static int dry_run_end(void *priv, size_t len)
> +{
> +struct domctl_context *c = priv;
> +
> +ASSERT(IS_ALIGNED(c->len, DOMAIN_CONTEXT_RECORD_ALIGN));
> +
> +return 0;
> +}
> +
> +static struct domain_save_ctxt_ops dry_run_ops = {
const? (sa
On 19.10.2020 16:10, Andrew Cooper wrote:
> On 19/10/2020 14:40, Jan Beulich wrote:
>> Of the state saved by the insn and reloaded by the corresponding VMLOAD
>> - TR, syscall, and sysenter state are invariant while having Xen's state
>> loaded,
>> - FS, GS, and LDTR are not used by Xen and get s
On 19/10/2020 14:40, Jan Beulich wrote:
> Of the state saved by the insn and reloaded by the corresponding VMLOAD
> - TR, syscall, and sysenter state are invariant while having Xen's state
> loaded,
> - FS, GS, and LDTR are not used by Xen and get suitably set in PV
> context switch code.
I th
On 08.10.2020 20:57, Paul Durrant wrote:
> +void __init domain_register_ctxt_type(unsigned int type, const char *name,
> + domain_save_ctxt_type save,
> + domain_load_ctxt_type load)
> +{
> +BUG_ON(type >= ARRAY_SIZE(fns)
On Fri, Oct 16, 2020 at 04:29:58PM +, George Dunlap wrote:
> https://gitlab.com/martyros/go-xen branch `working/xenops` contains a
> super-basic mock-up of a unix domain xenopsd based on the golang libxl
> bindings.
>
> To use:
>
> * Install Xen >= 4.14 on your target system
>
> * Make sur
On 08.10.2020 20:57, Paul Durrant wrote:
> --- /dev/null
> +++ b/xen/include/public/save.h
> @@ -0,0 +1,66 @@
> +/*
> + * save.h
> + *
> + * Structure definitions for common PV/HVM domain state that is held by Xen.
> + *
> + * Copyright Amazon.com Inc. or its affiliates.
> + *
> + * Permission is h
Of the state saved by the insn and reloaded by the corresponding VMLOAD
- TR, syscall, and sysenter state are invariant while having Xen's state
loaded,
- FS, GS, and LDTR are not used by Xen and get suitably set in PV
context switch code.
Suggested-by: Andrew Cooper
Signed-off-by: Jan Beulic
flight 155971 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155971/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 152631
test-amd64-amd64-
> On Jan 31, 2020, at 3:33 PM, Wei Liu wrote:
>
> On Fri, Jan 17, 2020 at 02:13:04PM -0500, Rich Persaud wrote:
>> On Aug 26, 2019, at 17:08, Pasi Kärkkäinen wrote:
>>> Hi,
>>>
On Mon, Oct 08, 2018 at 10:32:45AM -0400, Boris Ostrovsky wrote:
> On 10/3/18 11:51 AM, Pasi Kärkkäinen wr
flight 155974 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155974/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
Hi Thomas,
[SNIP]
+int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
+{
+ struct ttm_resource *mem = &bo->mem;
+ int ret;
+
+ ret = ttm_mem_io_reserve(bo->bdev, mem);
+ if (ret)
+ return ret;
+
+ if (mem->bus.is_iomem) {
+ void __iomem *vaddr_
flight 155965 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155965/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
Hi Christian
On 15.10.20 16:08, Christian König wrote:
> Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
>> The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
>> address space. The mapping's address is returned as struct dma_buf_map.
>> Each function is a simplified version
On 16.10.2020 17:38, Andrew Cooper wrote:
> On 15/10/2020 09:01, Jan Beulich wrote:
>> On 14.10.2020 15:57, Andrew Cooper wrote:
>>> On 13/10/2020 16:58, Jan Beulich wrote:
On 09.10.2020 17:09, Andrew Cooper wrote:
> At the time of XSA-170, the x86 instruction emulator really was broken,
With them depending on just the number of shadow levels, there's no need
for more than one instance of them, and hence no need for any hook (IOW
452219e24648 ["x86/shadow: monitor table is HVM-only"] didn't go quite
far enough). Move the functions to hvm.c while dropping the dead
is_pv_32bit_domain
By passing the functions an MFN and flags, only a single instance of
each is needed; they were pretty large for being inline functions
anyway.
While moving the code, also adjust coding style and add const where
sensible / possible.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/mm/s
This combination doesn't really make sense (and there likely are more);
in particular even if the code built with both options set, HVM guests
wouldn't work (and I think one wouldn't be able to create one in the
first place). The alternative here would be some presumably intrusive
#ifdef-ary to get
The change addressing the shadow related build issue noticed by
Andrew went in already. The build breakage goes beyond this
specific combination though - PV_SHIM_EXCLUSIVE plus HVM is
similarly an issue. This is what the 1st patch tries to take care
of, in a shape already on irc noticed to be contr
flight 155969 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155969/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 709b163940c55604b983400eb49dad144a2aa091
baseline version:
ovmf 73e3cb6c7eea4f5db81c8
With the split of libraries, I've observed a number of warnings from
(old?) ld.
Signed-off-by: Jan Beulich
---
It's unclear to me whether this is ld version dependent - the pattern
of where I've seen such warnings doesn't suggest a clear version
dependency.
--- a/tools/python/setup.py
+++ b/tool
On 16.10.2020 18:28, Jason Andryuk wrote:
> Looks like we can pass XC_DOM_PV_CONTAINER/XC_DOM_HVM_CONTAINER down
> into elf_xen_parse(). Then we would just validate phys_entry for HVM
> and virt_entry for PV. Does that sound reasonable?
I think so, yes. Assuming of course that you'll convert the
> -Original Message-
> From: Jan Beulich
> Sent: 19 October 2020 08:30
> To: p...@xen.org
> Cc: 'Julien Grall' ; xen-devel@lists.xenproject.org; 'Paul
> Durrant'
> ; 'Daniel De Graaf' ; 'Ian
> Jackson' ;
> 'Wei Liu' ; 'Andrew Cooper' ;
> 'George Dunlap'
> ; 'Stefano Stabellini'
> Subje
> -Original Message-
> From: Julien Grall
> Sent: 16 October 2020 16:55
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Ian Jackson ;
> Wei Liu ; Andrew
> Cooper ; George Dunlap ;
> Jan Beulich
> ; Stefano Stabellini ; Anthony
> PERARD
> ; Volodymyr Babchuk ;
>
On 19.10.2020 09:23, Paul Durrant wrote:
>> From: Julien Grall
>> Sent: 16 October 2020 16:47
>>
>> On 05/10/2020 10:49, Paul Durrant wrote:
>>> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
>>> index 791f0a2592..75e855625a 100644
>>> --- a/xen/include/public/domctl.h
>>>
> -Original Message-
> From: Julien Grall
> Sent: 16 October 2020 16:47
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Daniel De Graaf
> ; Ian Jackson
> ; Wei Liu ; Andrew Cooper
> ; George Dunlap
> ; Jan Beulich ; Stefano
> Stabellini
>
> Subject: Re: [PATCH
Unlike pattern rules, ordinary rules with multiple targets have their
commands executed once per target. Hence when $(LIBHEADERS) expands to
more than just one item, multiple identical commands would have been
issued, which have been observed to cause build failures relatively
frequently after libx
This again was working right only as long as $(LIBHEADER) consisted of
just one entry.
Signed-off-by: Jan Beulich
---
An alternative would be to use $(addprefix ) without any shell loop.
--- a/tools/libs/libs.mk
+++ b/tools/libs/libs.mk
@@ -107,7 +107,7 @@ install: build
.PHONY: uninstall
unin
1: fix header symlinking rule
2: fix uninstall rule for header files
Jan
65 matches
Mail list logo
