All,
On 19.07.2021 04:38, osstest service owner wrote:
> flight 163782 xen-unstable real [real]
> flight 163791 xen-unstable real-retest [real]
> http://logs.test-lab.xenproject.org/osstest/logs/163782/
> http://logs.test-lab.xenproject.org/osstest/logs/163791/
>
> Regressions :-(
>
> Tests whic
On 16.07.2021 18:14, Andrew Cooper wrote:
> On 16/07/2021 16:26, George Dunlap wrote:
>>
>>> On Jul 14, 2021, at 5:17 PM, Anthony PERARD
>>> wrote:
>>>
>>> This will help prevent the CI loop from having build failures when
>>> `checkpolicy` isn't available, when doing "randconfig" jobs.
>> Hang o
On 16.07.2021 14:38, Anthony PERARD wrote:
> This will help prevent the CI loop from having build failures when
> `checkpolicy` isn't available, when doing "randconfig" jobs.
>
> Also, move the check out of Config.mk and into xen/ build system.
> Nothing in tools/ is using that information as it's
On 05.07.2021 17:09, Jan Beulich wrote:
> ... or so I hope. This series continues the attempt to deal with
> the ovmf change putting the shared info page at a very high address
> (which is now planned to get reverted there, but the general
> problem doesn't go away by them doing so). There are furt
flight 163796 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163796/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-armhf-libvirt
flight 163788 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163788/
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-
On 15.07.2021 07:18, Penny Zheng wrote:
> This commit defines a new helper mark_page_free to extract common code,
> like following the same cache/TLB coherency policy, between free_heap_pages
> and the new function free_staticmem_pages, which will be introduced later.
>
> Signed-off-by: Penny Zhen
On 15.07.2021 07:18, Penny Zheng wrote:
> v3 change:
> - include addition of CONFIG_STATIC_ALLOCATION in this commit, where it
> is firstly used and also change the name to CONFIG_STATIC_MEMORY
> - Fix TAB typo in Kconfig
Not sure what this relates to, but ...
> --- a/xen/arch/arm/Kconfig
> +++ b
On 15.07.2021 07:18, Penny Zheng wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1519,6 +1519,26 @@ static void free_heap_pages(
> spin_unlock(&heap_lock);
> }
>
> +#ifdef CONFIG_STATIC_MEMORY
> +/* Equivalent of free_heap_pages to free nr_mfns pages of static m
On 15.07.2021 07:18, Penny Zheng wrote:
> In order to deal with the trouble of count-to-order conversion when page
> number
> is not in a power-of-two, this commit re-define assign_pages for nr pages and
> assign_page for original page with a single order.
>
> Backporting confusion could be helpe
Jan Beulich @ 2021-07-19 08:44 CEST:
> On 16.07.2021 22:08, Charles-H. Schulz wrote:
>> Jan Beulich @ 2021-07-16 17:21 CEST:
>>> On 16.07.2021 15:13, Charles-H. Schulz wrote:
Jan Beulich @ 2021-07-16 09:52 CEST:
> On 15.07.2021 23:23, Charles-H. Schulz wrote:
>> Hello,
>>
>>
On 16/07/2021 18:14, Bertrand Marquis wrote:
Hi Julien
Hi Bertrand,
[…]
+
+if ( old_reg != new_reg )
+printk(XENLOG_DEBUG "SANITY DIF: %s 0x%"PRIx64" -> 0x%"PRIx64"\n",
+ reg_name, old_reg, new_reg);
+if ( old_reg != *cur_reg )
+printk(XENLOG_DEBUG "
Hi Jan,
On 13/07/2021 08:22, Jan Beulich wrote:
In the original change I neglected to consider the case of us running as
L1 under another Xen. In this case we're not Dom0, so the underlying Xen
wouldn't permit us access to these MSRs. As an immediate workaround use
rdmsr_safe(); I don't view thi
On 19/07/2021 08:04, Jan Beulich wrote:
All,
Hi Jan,
On 19.07.2021 04:38, osstest service owner wrote:
flight 163782 xen-unstable real [real]
flight 163791 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/163782/
http://logs.test-lab.xenproject.org/osstest/
On Sat, Jul 17, 2021 at 11:39:21AM +0300, Roman Skakun wrote:
> > We can merge this patch and create a new one for
> > xen_swiotlb_free_coherent() later.
> > Yeah, no worries, I didn't know that exposing dma_common_vaddr_to_page
> > was problematic.
> >
> > This patch is fine by me.
>
> Good. I'm
On 15.07.2021 07:18, Penny Zheng wrote:
> @@ -1065,6 +1069,73 @@ static struct page_info *alloc_heap_pages(
> return pg;
> }
>
> +#ifdef CONFIG_STATIC_MEMORY
> +/*
> + * Acquire nr_mfns contiguous reserved pages, starting at #smfn, of
> + * static memory.
> + */
> +static struct page_info *
On 19.07.2021 11:18, Julien Grall wrote:
> On 13/07/2021 08:22, Jan Beulich wrote:
>> In the original change I neglected to consider the case of us running as
>> L1 under another Xen. In this case we're not Dom0, so the underlying Xen
>> wouldn't permit us access to these MSRs. As an immediate work
Hi Jan,
On 19/07/2021 10:26, Jan Beulich wrote:
On 15.07.2021 07:18, Penny Zheng wrote:
@@ -1065,6 +1069,73 @@ static struct page_info *alloc_heap_pages(
return pg;
}
+#ifdef CONFIG_STATIC_MEMORY
+/*
+ * Acquire nr_mfns contiguous reserved pages, starting at #smfn, of
+ * static mem
On 12.07.2021 22:32, Daniel P. Smith wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -200,23 +200,20 @@ config XENOPROF
>
> If unsure, say Y.
>
> -config XSM
> - bool "Xen Security Modules support"
> - default ARM
> - ---help---
> - Enables the securi
Ian,
On 15.07.2021 09:58, Jan Beulich wrote:
> Beyond this I'd like the following to be considered:
>
> 6409210a5f51 libxencall: osdep_hypercall() should return long
> bef64f2c0019 libxencall: introduce variant of xencall2() returning long
> 01a2d001dea2 libxencall: Bump SONAME following new func
On Mon, Jul 19, 2021 at 09:37:06AM +0200, Jan Beulich wrote:
> On 16.07.2021 14:38, Anthony PERARD wrote:
> > +export HAS_CHECKPOLICY := $(call success,$(CHECKPOLICY) -h 2>&1 | grep -q
> > xen)
>
> While the setting indeed gets obtained in a Makefile now, ...
>
> > --- a/xen/common/Kconfig
> > +
On 19.07.2021 12:47, Anthony PERARD wrote:
> On Mon, Jul 19, 2021 at 09:37:06AM +0200, Jan Beulich wrote:
>> On 16.07.2021 14:38, Anthony PERARD wrote:
>>> +export HAS_CHECKPOLICY := $(call success,$(CHECKPOLICY) -h 2>&1 | grep -q
>>> xen)
>>
>> While the setting indeed gets obtained in a Makefile
hvm_load() is currently a mix of -errno and -1 style error handling, which
aliases -EPERM. This leads to the following confusing diagnostics:
>From userspace:
xc: info: Restoring domain
xc: error: Unable to restore HVM context (1 = Operation not permitted):
Internal error
xc: error: Restor
flight 163794 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163794/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
On 19.07.2021 13:14, Andrew Cooper wrote:
> hvm_load() is currently a mix of -errno and -1 style error handling, which
> aliases -EPERM. This leads to the following confusing diagnostics:
>
> From userspace:
> xc: info: Restoring domain
> xc: error: Unable to restore HVM context (1 = Operatio
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt-xsm
testid guest-start
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbit
On 19/07/2021 13:46, Jan Beulich wrote:
> On 19.07.2021 13:14, Andrew Cooper wrote:
>> hvm_load() is currently a mix of -errno and -1 style error handling,
>> which
>> aliases -EPERM. This leads to the following confusing diagnostics:
>>
>> From userspace:
>> xc: info: Restoring domain
>> xc: error
flight 163793 xen-unstable real [real]
flight 163805 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/163793/
http://logs.test-lab.xenproject.org/osstest/logs/163805/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
A platform introduced in EDK II named OvmfXen is now the one to use for
Xen instead of OvmfX64. It comes with PVH support.
Also, the Xen support in OvmfX64 is deprecated,
"deprecation notice: *dynamic* multi-VMM (QEMU vs. Xen) support in OvmfPkg"
https://edk2.groups.io/g/devel/message/7549
On 19 Jul 2021, at 12:04, Jan Beulich
mailto:jbeul...@suse.com>> wrote:
On 19.07.2021 12:47, Anthony PERARD wrote:
On Mon, Jul 19, 2021 at 09:37:06AM +0200, Jan Beulich wrote:
On 16.07.2021 14:38, Anthony PERARD wrote:
+export HAS_CHECKPOLICY := $(call success,$(CHECKPOLICY) -h 2>&1 | grep -q x
flight 163803 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163803/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 163798 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163798/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 12 debian-hvm-install fail
REGR. vs. 163321
te
On 7/15/21 12:45 PM, Logan Gunthorpe wrote:
> From: Martin Oliveira
>
> The .map_sg() op now expects an error code instead of zero on failure.
>
> xen_swiotlb_map_sg() may only fail if xen_swiotlb_map_page() fails, but
> xen_swiotlb_map_page() only supports returning errors as
> DMA_MAPPING_ERRO
flight 163813 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163813/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 163806 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163806/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
flight 163800 linux-5.4 real [real]
flight 163818 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/163800/
http://logs.test-lab.xenproject.org/osstest/logs/163818/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd6
flight 163801 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163801/
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-
flight 163809 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163809/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 16 xen-boot/l1 fail REGR. vs. 163458
Tests which are fa
flight 163811 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163811/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 12 debian-hvm-install fail REGR. vs.
163321
test-amd64
flight 163819 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163819/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
40 matches
Mail list logo
