1: fix header symlinking rule
2: fix uninstall rule for header files
Jan
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
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
> -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
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: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 ;
>
> -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
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
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
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
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
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
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
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
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,
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 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 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
> 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 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-
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
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
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 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 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 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 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 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 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
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: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
>>>
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 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 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
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 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
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
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 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
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
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 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
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 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 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
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
-
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
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
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
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
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
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
> 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 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
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
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
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 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 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 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 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 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 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
65 matches
Mail list logo
