flight 154374 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154374/
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 16/09/2020 09:13, Paul Durrant wrote:
-Original Message-
From: Jan Beulich
Sent: 16 September 2020 09:05
To: Oleksandr Tyshchenko ; Paul Durrant
Cc: xen-devel@lists.xenproject.org; Oleksandr Tyshchenko
; Stefano
Stabellini ; Julien Grall ; Volodymyr
Babchuk
; Andrew Cooper ;
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -1155,6 +1155,7 @@ static int acquire_resource(
> xen_pfn_t gfn_list[ARRAY_SIZE(mfn_list)];
> unsigned int i;
>
> +#ifndef CONFIG_ARM
> /*
> * FIXME:
The passed in domain doesn't get altered and hence can be const. While
modifying its prototype anyway, also switch to bool.
Signed-off-by: Jan Beulich
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1560,17 +1560,17 @@ void put_page(struct page_info *page)
}
}
-int get_page(struct
flight 154376 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154376/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7bcb021a6d54c5775c0fa1a3ea003b61f5c966ed
baseline version:
ovmf
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
> @@ -2277,8 +2299,10 @@ void leave_hypervisor_to_guest(void)
> {
> local_irq_disable();
>
> -check_for_vcpu_work();
> -check_for_pcpu_work();
> +do
> +{
> +check_for_pcpu_work();
> +} while (
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This patch introduces a helper the main purpose of which is to check
> if a domain is using IOREQ server(s).
>
> On Arm the benefit is to avoid calling handle_hvm_io_completion()
> (which implies iterating over
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -635,7 +635,8 @@ int p2m_is_logdirty_range(struct p2m_domain *, unsigned
> long start,
>unsigned long end);
>
> /* Set foreign entry in the p2m
> -Original Message-
> From: Jan Beulich
> Sent: 16 September 2020 09:05
> To: Oleksandr Tyshchenko ; Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Oleksandr Tyshchenko
> ; Stefano
> Stabellini ; Julien Grall ; Volodymyr
> Babchuk
> ; Andrew Cooper ; Wei
> Liu ; Roger
> Pau Monné
On Wednesday, September 16, 2020 3:32 AM, Roger Pau Monné
wrote:
> On Mon, Sep 14, 2020 at 07:50:12AM -0400, Trammell Hudson wrote:
> > - s2w(_string);
>
> Don't you need to check that s2w succeed, so that name_string.w is not
> a random pointer from stack garbage?
Maybe? I don't see anywhere
"mem" in the name already indicates the root, similar to
release_mem_region() and devm_request_mem_region(). Make it implicit.
The only single caller always passes iomem_resource, other parents are
not applicable.
Suggested-by: Wei Yang
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Dan Williams
Cc:
Hi Jan,
On 16/09/2020 08:28, Jan Beulich wrote:
The passed in domain doesn't get altered and hence can be const. While
modifying its prototype anyway, also switch to bool.
Reviewed-by: Julien Grall
Cheers,
Signed-off-by: Jan Beulich
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@
Hi Paul,
On 15/09/2020 09:29, Paul Durrant wrote:
From: Paul Durrant
The 'legacy' functions do implicit flushing so amend the callers to do the
appropriate flushing.
Unfortunately, because of the structure of the P2M code, we cannot remove
the per-CPU 'iommu_dont_flush_iotlb' global and the
Hi Paul,
On 15/09/2020 09:29, Paul Durrant wrote:
From: Paul Durrant
This patch avoids calling iommu_iotlb_flush() for each individual GNTTABOP and
instead calls iommu_iotlb_flush_all() at the end of a batch. This should mean
non-singleton map/unmap operations perform better.
NOTE: A batch
On 15.09.2020 19:53, Andrew Cooper wrote:
> Coverity points out that the "d &&" is redundant.
How can it know that ...
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -1336,7 +1336,7 @@ void set_gpfn_from_mfn(unsigned long mfn, unsigned long
> pfn)
> {
>
On 16.09.2020 10:50, Trammell Hudson wrote:
> On Wednesday, September 16, 2020 3:45 AM, Roger Pau Monné
> wrote:
>> On Mon, Sep 14, 2020 at 07:50:13AM -0400, Trammell Hudson wrote:
>>> If secure boot is enabled, the Xen command line arguments are ignored.
>>> If a unified Xen image is used, then
On Wed, Sep 16, 2020 at 09:30:41AM +0200, David Hildenbrand wrote:
>"mem" in the name already indicates the root, similar to
>release_mem_region() and devm_request_mem_region(). Make it implicit.
>The only single caller always passes iomem_resource, other parents are
>not applicable.
>
Looks good
On Tue, Sep 15, 2020 at 04:59:41PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in exynos. The only exception is gem_prime_mmap,
> which is
On 16.09.20 12:02, Wei Yang wrote:
> On Wed, Sep 16, 2020 at 09:30:41AM +0200, David Hildenbrand wrote:
>> "mem" in the name already indicates the root, similar to
>> release_mem_region() and devm_request_mem_region(). Make it implicit.
>> The only single caller always passes iomem_resource, other
flight 154380 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154380/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 51526576219f122ec7ccfd55dea95afbca70d330
baseline version:
xen
Hi
Am 16.09.20 um 12:03 schrieb Daniel Vetter:
> On Tue, Sep 15, 2020 at 04:59:41PM +0200, Thomas Zimmermann wrote:
>> GEM object functions deprecate several similar callback interfaces in
>> struct drm_driver. This patch replaces the per-driver callbacks with
>> per-instance callbacks in exynos.
Hi,
On 16/09/2020 08:17, Jan Beulich wrote:
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1155,6 +1155,7 @@ static int acquire_resource(
xen_pfn_t gfn_list[ARRAY_SIZE(mfn_list)];
unsigned int i;
+#ifndef
On 16.09.2020 10:50, Julien Grall wrote:
> On 16/09/2020 08:17, Jan Beulich wrote:
>> On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
>>> for ( i = 0; !rc && i < xmar.nr_frames; i++ )
>>> {
>>> -rc = set_foreign_p2m_entry(currd, gfn_list[i],
>>> +rc =
On 16/09/2020 10:09, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 16 September 2020 10:07
To: Jan Beulich ; Oleksandr Tyshchenko
Cc: xen-devel@lists.xenproject.org; Oleksandr Tyshchenko
; Paul Durrant
; Stefano Stabellini ; Julien Grall
Subject: Re: [PATCH V1
flight 154378 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154378/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8028b2907e20b21cd7d69639a36ac82a77c81dc1
baseline version:
ovmf
On 16.09.2020 10:37, Trammell Hudson wrote:
> On Wednesday, September 16, 2020 3:32 AM, Roger Pau Monné
> wrote:
>> On Mon, Sep 14, 2020 at 07:50:12AM -0400, Trammell Hudson wrote:
>>> - s2w(_string);
>>
>> Don't you need to check that s2w succeed, so that name_string.w is not
>> a random
> -Original Message-
> From: Julien Grall
> Sent: 16 September 2020 09:39
> To: p...@xen.org; 'Jan Beulich' ; 'Oleksandr Tyshchenko'
>
> Cc: xen-devel@lists.xenproject.org; 'Oleksandr Tyshchenko'
> ; 'Stefano
> Stabellini' ; 'Volodymyr Babchuk'
> ; 'Andrew
> Cooper' ; 'Wei Liu' ;
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -1490,6 +1490,12 @@ static void do_trap_hypercall(struct cpu_user_regs
> *regs, register_t *nr,
> /* Ensure the hypercall trap instruction is re-executed. */
> if (
On Wednesday, September 16, 2020 3:45 AM, Roger Pau Monné
wrote:
> On Mon, Sep 14, 2020 at 07:50:13AM -0400, Trammell Hudson wrote:
> > If secure boot is enabled, the Xen command line arguments are ignored.
> > If a unified Xen image is used, then the bundled configuration, dom0
> > kernel, and
On 16/09/2020 09:52, Jan Beulich wrote:
On 16.09.2020 10:50, Julien Grall wrote:
On 16/09/2020 08:17, Jan Beulich wrote:
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
for ( i = 0; !rc && i < xmar.nr_frames; i++ )
{
-rc = set_foreign_p2m_entry(currd,
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
> @@ -1325,7 +1327,7 @@ static int hvm_send_buffered_ioreq(struct
> hvm_ioreq_server *s, ioreq_t *p)
>
> new.read_pointer = old.read_pointer - n * IOREQ_BUFFER_SLOT_NUM;
> new.write_pointer = old.write_pointer - n *
> -Original Message-
> From: Jan Beulich
> Sent: 16 September 2020 10:04
> To: Oleksandr Tyshchenko
> Cc: xen-devel@lists.xenproject.org; Oleksandr Tyshchenko
> ; Paul Durrant
> ; Julien Grall ; Stefano Stabellini
> ; Julien
> Grall
> Subject: Re: [PATCH V1 14/16] xen/ioreq: Use
On 16/09/2020 10:04, Jan Beulich wrote:
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
@@ -1325,7 +1327,7 @@ static int hvm_send_buffered_ioreq(struct
hvm_ioreq_server *s, ioreq_t *p)
new.read_pointer = old.read_pointer - n * IOREQ_BUFFER_SLOT_NUM;
> -Original Message-
> From: Julien Grall
> Sent: 16 September 2020 10:07
> To: Jan Beulich ; Oleksandr Tyshchenko
>
> Cc: xen-devel@lists.xenproject.org; Oleksandr Tyshchenko
> ; Paul Durrant
> ; Stefano Stabellini ; Julien Grall
>
> Subject: Re: [PATCH V1 14/16] xen/ioreq: Use
This patch set adds multicore capability to the ARINC653 scheduler, based on the
guidance presented in the CAST-32A position paper. This approach only allows for
a single domain to run at any given time, but that domain is now able to use
multiple vCPUs running across the available pCPUs.
There
Function definitions in the arinc653 module did not follow the Xen
coding style. Furthermore, a few function names used a different prefix.
This change cleans up the definitions to be consistent with the Xen
coding style, and has no functional changes.
Signed-off-by: Jeff Kubascik
---
On Mon, Sep 14, 2020 at 07:50:10AM -0400, Trammell Hudson wrote:
> The config file, kernel, initrd, etc should only be freed if they
> are allocated with the UEFI allocator.
>
> Signed-off-by: Trammell Hudson
Reviewed-by: Roger Pau Monné
> ---
> xen/common/efi/boot.c | 10 ++
> 1
flight 154371 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154371/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 152332
On Mon, Sep 14, 2020 at 07:50:11AM -0400, Trammell Hudson wrote:
> Add a separate function to display the address ranges used by
> the files and call `efi_arch_handle_module()` on the modules.
>
> Signed-off-by: Trammell Hudson
Reviewed-by: Roger Pau Monné
Thanks!
On Tue, Sep 15, 2020 at 04:59:40PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in etnaviv. The only exception is gem_prime_mmap,
> which is
On Wed, Sep 16, 2020 at 12:36:28PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 16.09.20 um 12:03 schrieb Daniel Vetter:
> > On Tue, Sep 15, 2020 at 04:59:41PM +0200, Thomas Zimmermann wrote:
> >> GEM object functions deprecate several similar callback interfaces in
> >> struct drm_driver. This
On Tue, Sep 15, 2020 at 04:59:42PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in gma500.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by:
On Mon, Sep 14, 2020 at 07:50:12AM -0400, Trammell Hudson wrote:
> This patch adds support for bundling the xen.efi hypervisor, the xen.cfg
> configuration file, the Linux kernel and initrd, as well as the XSM,
> and architectural specific files into a single "unified" EFI executable.
> This
On Tue, Sep 15, 2020 at 04:59:44PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in mediatek. The only exception is gem_prime_mmap,
> which is
On Mon, Sep 14, 2020 at 07:50:13AM -0400, Trammell Hudson wrote:
> If secure boot is enabled, the Xen command line arguments are ignored.
> If a unified Xen image is used, then the bundled configuration, dom0
> kernel, and initrd are prefered over the ones listed in the config file.
I understand
On Tue, Sep 15, 2020 at 04:59:45PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in msm. The only exception is gem_prime_mmap,
> which is
On Fri, Sep 11, 2020 at 12:34:56PM +0200, David Hildenbrand wrote:
>Some add_memory*() users add memory in small, contiguous memory blocks.
>Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
>
>This can quickly result in a lot of memory resources, whereby the actual
>resource
On Wed, Sep 16, 2020 at 08:37:44AM +, Trammell Hudson wrote:
> On Wednesday, September 16, 2020 3:32 AM, Roger Pau Monné
> wrote:
> > On Mon, Sep 14, 2020 at 07:50:12AM -0400, Trammell Hudson wrote:
> > > - s2w(_string);
> >
> > Don't you need to check that s2w succeed, so that
Address at least the primary reason why 52bba67f8b87 ("efi/boot: Don't
free ebmalloc area at all") was put in place: Make xen_in_range() aware
of the freed range. This is in particular relevant for EFI-enabled
builds not actually running on EFI, as the entire range will be unused
in this case.
On Wed, Sep 16, 2020 at 02:16:25PM +0200, David Hildenbrand wrote:
>On 16.09.20 14:10, Wei Yang wrote:
>> On Wed, Sep 16, 2020 at 12:03:20PM +0200, David Hildenbrand wrote:
>>> On 16.09.20 12:02, Wei Yang wrote:
On Wed, Sep 16, 2020 at 09:30:41AM +0200, David Hildenbrand wrote:
> "mem" in
On 16.09.2020 15:04, Roger Pau Monné wrote:
> On Wed, Sep 16, 2020 at 02:55:52PM +0200, Jan Beulich wrote:
>> On 16.09.2020 12:54, Roger Pau Monne wrote:
>>> Windows 10 will try to unconditionally read EX_CFG on AMD hadrware,
>>> and injecting a #GP fault will result in a panic:
>>>
>>>
On Wed, Sep 16, 2020 at 09:28:47AM +0200, Jan Beulich wrote:
> The passed in domain doesn't get altered and hence can be const. While
> modifying its prototype anyway, also switch to bool.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks, Roger.
On Wed, Sep 16, 2020 at 12:03:20PM +0200, David Hildenbrand wrote:
>On 16.09.20 12:02, Wei Yang wrote:
>> On Wed, Sep 16, 2020 at 09:30:41AM +0200, David Hildenbrand wrote:
>>> "mem" in the name already indicates the root, similar to
>>> release_mem_region() and devm_request_mem_region(). Make it
The first change is simply addressing a build issue noticed by
Andrew. The build breakage goes beyond this specific combination
though - PV_SHIM_EXCLUSIVE plus HVM is similarly an issue. This
is what the last patch tries to take care of, in a shape already
on irc noticed to be controversial. I'm
On Tue, Sep 15, 2020 at 04:59:46PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in nouveau.
>
> Signed-off-by: Thomas Zimmermann
Hm ttm and
On 16.09.2020 12:54, Roger Pau Monne wrote:
> Windows 10 will try to unconditionally read EX_CFG on AMD hadrware,
> and injecting a #GP fault will result in a panic:
>
> svm.c:1964:d5v0 RDMSR 0xc001102c unimplemented
> d5v0 VIRIDIAN CRASH: 7e c096 f8054cbe5ffe fa0837a066e8
>
On Tue, Sep 15, 2020 at 04:59:58PM +0200, Thomas Zimmermann wrote:
> Several GEM and PRIME callbacks have been deprecated in favor of
> per-instance GEM object functions. Remove the callbacks as they are
> now unused. The only exception is .gem_prime_mmap, which is still
> in use by several
Hello,
thanks for your infos. it appears the compilation process is not really
straightforward.
I had to patch some header files. then some of the firmwares were bugged.
So I disabled some various checks in the firmwares Makefiles.
I ended up with a:
"no target for make all":
configure passed
On Tue, Sep 15, 2020 at 04:59:54PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces virtgpu's per-driver PRIME export
> function with a per-object function.
>
> Signed-off-by: Thomas Zimmermann
flight 154381 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154381/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Fri, Sep 11, 2020 at 12:34:58PM +0200, David Hildenbrand wrote:
>Let's try to merge system ram resources we add, to minimize the number
>of resources in /proc/iomem. We don't care about the boundaries of
>individual chunks we added.
>
>Reviewed-by: Juergen Gross
>Cc: Andrew Morton
>Cc: Michal
On Fri, Sep 11, 2020 at 12:34:59PM +0200, David Hildenbrand wrote:
>Let's try to merge system ram resources we add, to minimize the number
>of resources in /proc/iomem. We don't care about the boundaries of
>individual chunks we added.
>
>Reviewed-by: Wei Liu
>Cc: Andrew Morton
>Cc: Michal Hocko
On Fri, Sep 11, 2020 at 12:34:57PM +0200, David Hildenbrand wrote:
>virtio-mem adds memory in memory block granularity, to be able to
>remove it in the same granularity again later, and to grow slowly on
>demand. This, however, results in quite a lot of resources when
>adding a lot of memory.
Examples of compile bugs for xen-stable-4.11
for make dist-tools:
"include/ipxe/uri.h:178:12: error: taking address of packed member of
‘struct uri’ may result in an unaligned pointer value
[-Werror=address-of-packed-member]
178 | ref_get ( >refcnt );"
-> fixed by adding the Cflag
Windows 10 will try to unconditionally read EX_CFG on AMD hadrware,
and injecting a #GP fault will result in a panic:
svm.c:1964:d5v0 RDMSR 0xc001102c unimplemented
d5v0 VIRIDIAN CRASH: 7e c096 f8054cbe5ffe fa0837a066e8
fa0837a05f30
Return 0 when trying to read the MSR
On 16.09.20 14:10, Wei Yang wrote:
> On Wed, Sep 16, 2020 at 12:03:20PM +0200, David Hildenbrand wrote:
>> On 16.09.20 12:02, Wei Yang wrote:
>>> On Wed, Sep 16, 2020 at 09:30:41AM +0200, David Hildenbrand wrote:
"mem" in the name already indicates the root, similar to
Kevin, ping?
This patch hasn't changed since v2.
Paul
> -Original Message-
> From: Paul Durrant
> Sent: 11 September 2020 09:20
> To: xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Jan Beulich ;
> Kevin Tian
>
> Subject: [PATCH v8 1/8] x86/iommu: convert VT-d code to use new
Just like HVM, defaulting SHADOW_PAGING and TBOOT to Yes in shim-
exclusive mode makes no sense, as the respective code is dead there.
Also adjust the shim default config file: It needs to specifiy values
only for settings where a non-default value is wanted.
Signed-off-by: Jan Beulich
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
While there's little point in enabling both, the combination ought to at
least build correctly. Drop the direct PV_SHIM_EXCLUSIVE conditionals
and instead zap PG_log_dirty to zero under the right conditions, and key
other #ifdef-s off of that.
While there also expand on ded576ce07e9 ("x86/shadow:
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.
---
Andrew Cooper writes ("[PATCH] tools: Delete XEN_DOMCTL_disable_migrate"):
> It is conceptually wrong for this information to exist in the hypervisor in
> the first place. Only the toolstack is capable of correctly reasoning about
> the non-migrateability of guests.
>
> This hypercall has only
On Tue, Sep 15, 2020 at 04:59:50PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in rockchip. The only exception is gem_prime_mmap,
> which is
On 15.09.2020 18:17, Paul Durrant wrote:
> +static int load_shared_info(struct domain *d, struct domain_context *c)
> +{
> +struct domain_shared_info_context ctxt;
> +size_t hdr_size = offsetof(typeof(ctxt), buffer);
> +unsigned int i;
> +int rc;
> +
> +rc =
Page isolation doesn't actually touch the pages, it simply isolates
pageblocks and moves all free pages to the MIGRATE_ISOLATE freelist.
We already place pages to the tail of the freelists when undoing
isolation via __putback_isolated_page(), let's do it in any case
(e.g., if order ==
__putback_isolated_page() already documents that pages will be placed to
the tail of the freelist - this is, however, not the case for
"order >= MAX_ORDER - 2" (see buddy_merge_likely()) - which should be
the case for all existing users.
This change affects two users:
- free page reporting
- page
__free_pages_core() is used when exposing fresh memory to the buddy
during system boot and when onlining memory in generic_online_page().
generic_online_page() is used in two cases:
1. Direct memory onlining in online_pages().
2. Deferred memory onlining in memory-ballooning-like mechanisms
When adding separate memory blocks via add_memory*() and onlining them
immediately, the metadata (especially the memmap) of the next block will be
placed onto one of the just added+onlined block. This creates a chain
of unmovable allocations: If the last memory block cannot get
offlined+removed()
Let's prepare for additional flags and avoid long parameter lists of bools.
Follow-up patches will also make use of the flags in __free_pages_ok(),
however, I wasn't able to come up with a better name for the type - should
be good enough for internal purposes.
Cc: Andrew Morton
Cc: Alexander
On 2020-09-16 20:34, David Hildenbrand wrote:
When adding separate memory blocks via add_memory*() and onlining them
immediately, the metadata (especially the memmap) of the next block
will be
placed onto one of the just added+onlined block. This creates a chain
of unmovable allocations: If
flight 154386 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154386/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 152332
On Wed, Sep 16, 2020 at 03:28:28PM +0200, Jan Beulich wrote:
> On 16.09.2020 15:04, Roger Pau Monné wrote:
> > On Wed, Sep 16, 2020 at 02:55:52PM +0200, Jan Beulich wrote:
> >> On 16.09.2020 12:54, Roger Pau Monne wrote:
> >>> Windows 10 will try to unconditionally read EX_CFG on AMD hadrware,
>
On Wed, Sep 16, David I wrote:
> So, how did the debian package was compiled ? is this the same source code
> with
> different options ?
Xen 4.11 is from 2018. Use also a compiler from that year.
Using this years compiler will lead to errors...
Olaf
signature.asc
Description: PGP signature
Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:
> Several GEM and PRIME callbacks have been deprecated in favor of
> per-instance GEM object functions. Remove the callbacks as they are
> now unused. The only exception is .gem_prime_mmap, which is still
> in use by several drivers.
>
> What is
On 22/07/20 10:25, Philippe Mathieu-Daudé wrote:
> Xen accelerator requires specific changes to a machine to be able
> to use it. See for example the 'Xen PC' machine configure its PCI
> bus calling pc_xen_hvm_init_pci(). There is no 'Xen Q35' machine
> declared. This code was probably added while
On Wed, Sep 16, 2020 at 02:55:52PM +0200, Jan Beulich wrote:
> On 16.09.2020 12:54, Roger Pau Monne wrote:
> > Windows 10 will try to unconditionally read EX_CFG on AMD hadrware,
> > and injecting a #GP fault will result in a panic:
> >
> > svm.c:1964:d5v0 RDMSR 0xc001102c unimplemented
> > d5v0
On 14/09/2020 15:26, Daniel Wagner2 wrote:
Hi Julien,
Hi Daniel,
I am moving the thread to xen-devel and adding a couple of more folks.
this is the full version of the fdt that threw the error:
https://pastebin.com/63TZ9z3k
The problematic memory node appears in line 126
Thanks! The
branch xen-unstable
xenbranch xen-unstable
job test-armhf-armhf-libvirt-raw
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
Hi Oleksandr,
On 14/09/2020 20:37, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
And remove dependencies on CONFIG_EXPERT.
In order to help to make the decision, can you provide the following
information:
- Is it functionally complete?
- Can it work on all known platforms
This converts existing DECLARE_OBJ_CHECKERS usage to
OBJECT_DECLARE_TYPE when possible.
$ ./scripts/codeconverter/converter.py -i \
--pattern=AddObjectDeclareType $(git grep -l '' -- '*.[ch]')
Signed-off-by: Eduardo Habkost
---
Cc: Peter Maydell
Cc: Andrzej Zaborowski
Cc: Alistair Francis
One of the goals of having less boilerplate on QOM declarations
is to avoid human error. Requiring an extra argument that is
never used is an opportunity for mistakes.
Remove the unused argument from OBJECT_DECLARE_TYPE and
OBJECT_DECLARE_SIMPLE_TYPE.
Coccinelle patch used to convert all users
> Am 16.09.2020 um 20:50 schrieb osalva...@suse.de:
>
> On 2020-09-16 20:34, David Hildenbrand wrote:
>> When adding separate memory blocks via add_memory*() and onlining them
>> immediately, the metadata (especially the memmap) of the next block will be
>> placed onto one of the just
On Wed, Sep 16, 2020 at 11:34 AM David Hildenbrand wrote:
>
> Let's prepare for additional flags and avoid long parameter lists of bools.
> Follow-up patches will also make use of the flags in __free_pages_ok(),
> however, I wasn't able to come up with a better name for the type - should
> be
On Wed, 16 Sep 2020, Julien Grall wrote:
> On 14/09/2020 15:26, Daniel Wagner2 wrote:
> > Hi Julien,
>
> Hi Daniel,
>
> I am moving the thread to xen-devel and adding a couple of more folks.
>
> > >
> > > >
> > > > this is the full version of the fdt that threw the error:
> > > >
On 9/16/20 6:12 PM, Olaf Hering wrote:
> On Wed, Sep 16, David I wrote:
>
>> So, how did the debian package was compiled ? is this the same source code
>> with
>> different options ?
>
> Xen 4.11 is from 2018. Use also a compiler from that year.
> Using this years compiler will lead to
On Thu, 17 Sep 2020, Oleksandr Tyshchenko wrote:
> On Wed, Sep 16, 2020 at 8:02 PM Julien Grall wrote:
> Hi Oleksandr,
>
>
> Hi Julien
>
> [sorry for the possible format issues]
>
>
> On 14/09/2020 20:37, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko
>
On Wed, 16 Sep 2020, Julien Grall wrote:
> Hi Oleksandr,
>
> On 14/09/2020 20:37, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko
> >
> > And remove dependencies on CONFIG_EXPERT.
>
> In order to help to make the decision, can you provide the following
> information:
>- Is it
On Wed, Sep 16, 2020 at 8:02 PM Julien Grall wrote:
> Hi Oleksandr,
>
Hi Julien
[sorry for the possible format issues]
>
> On 14/09/2020 20:37, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko
> >
> > And remove dependencies on CONFIG_EXPERT.
>
> In order to help to make the
On Wed, Sep 16, 2020 at 11:34 AM David Hildenbrand wrote:
>
> __putback_isolated_page() already documents that pages will be placed to
> the tail of the freelist - this is, however, not the case for
> "order >= MAX_ORDER - 2" (see buddy_merge_likely()) - which should be
> the case for all
flight 154399 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154399/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 152332
1 - 100 of 104 matches
Mail list logo
