flight 146616 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146616/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
flight 146613 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146613/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
flight 146610 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146610/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
flight 146603 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146603/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121
On 30/01/2020 23:14, Igor Druzhinin wrote:
> I was debugging constant freezes of PV shim on AMD hardware
> after going out of a long suspend. As it turned out the root cause
> of this is platform time jumping forward to the amount of time
> spent in suspended state. On Intel this issue is papered
flight 146608 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146608/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
flight 146600 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146600/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-amd 7 xen-bootfail REGR. vs. 146563
flight 146601 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146601/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
I was debugging constant freezes of PV shim on AMD hardware
after going out of a long suspend. As it turned out the root cause
of this is platform time jumping forward to the amount of time
spent in suspended state. On Intel this issue is papered over
by CONSTANT_TSC being set which avoids CPU
flight 146602 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146602/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
flight 146604 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146604/
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 Wed, Jan 29, 2020 at 04:33:02PM +0100, Jan Beulich wrote:
> On 29.01.2020 16:28, Jan Beulich wrote:
> > On 17.01.2020 11:53, Anthony PERARD wrote:
> >> It isn't necessary to include Config.mk here because this Makefile is
> >> only used by xen/Rules.mk which already includes Config.mk.
> >
> >
On 30/01/2020 17:42, Durrant, Paul wrote:
>> -Original Message-
>> From: Ian Jackson
>> Sent: 30 January 2020 17:29
>> To: Durrant, Paul
>> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony Perard
>>
>> Subject: Re: [PATCH v4 7/7] xl: allow domid to be preserved on
>> save/restore
On Wed, Jan 29, 2020 at 03:30:19PM +0100, Jan Beulich wrote:
> On 17.01.2020 11:53, Anthony PERARD wrote:
> > From: Anthony PERARD
> >
> > Most of the code executed by Rules.mk isn't necessary for the clean
> > target, especially not the CFLAGS. This make running make clean much
> > faster.
> >
> > Hi. (I'm replying to the 1/ here because I don't seem to have any 0/
> > in my inbox...)
>
> Oh, I must have forgot to copy the combined cc list onto the cover letter.
> Sorry about that.
There's a bug in git-send-email in this area.
> Don't worry, your feedback is fine... certainly not
On 30/01/2020 16:56, Wei Liu wrote:
> On Thu, Jan 30, 2020 at 05:47:03PM +0100, Jan Beulich wrote:
>> Don't silently ignore the upper 32 bits.
>>
>> Signed-off-by: Jan Beulich
> Reviewed-by: Wei Liu
Acked-by: Andrew Cooper
___
Xen-devel mailing list
> -Original Message-
> From: Ian Jackson
> Sent: 30 January 2020 17:29
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony Perard
>
> Subject: Re: [PATCH v4 7/7] xl: allow domid to be preserved on
> save/restore or migrate
>
> Paul Durrant writes ("[PATCH v4
> -Original Message-
> From: Xen-devel On Behalf Of Ian
> Jackson
> Sent: 30 January 2020 17:32
> To: Durrant, Paul
> Cc: Anthony Perard ; xen-
> de...@lists.xenproject.org; Wei Liu
> Subject: Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of
> INVALID_DOMID to the API
>
> Paul
> -Original Message-
> From: Ian Jackson
> Sent: 30 January 2020 17:26
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony Perard
> ; Andrew Cooper ;
> George Dunlap ; Jan Beulich ;
> Julien Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ;
> Jason Andryuk
>
Paul Durrant writes ("[PATCH v4 1/7] libxl: add definition of INVALID_DOMID to
the API"):
> Currently both xl and libxl have internal definitions of INVALID_DOMID
> which happen to be identical. However, for the purposes of describing the
> behaviour of libxl_domain_create_new/restore() it is
Paul Durrant writes ("[PATCH v4 7/7] xl: allow domid to be preserved on
save/restore or migrate"):
> This patch adds a '-D' command line option to save and migrate to allow
> the domain id to be incorporated into the saved domain configuration and
> hence be preserved.
Thanks.
In response to v3
Paul Durrant writes ("[PATCH v4 5/7] libxl: allow creation of domains with a
specified or random domid"):
> This patch adds a 'domid' field to libxl_domain_create_info and then
> modifies libxl__domain_make() to have Xen use that value if it is valid.
> If the domid value is invalid then Xen will
Paul Durrant writes ("[PATCH v4 4/7] libxl: add infrastructure to track and
query 'recent' domids"):
> A domid is considered recent if the domain it represents was destroyed
> less than a specified number of seconds ago. The number can be set using
> the environment variable
Paul Durrant writes ("[PATCH v4 3/7] libxl: generalise
libxl__domain_userdata_lock()"):
> This function implements a file-based lock with a file name generated
> from a domid.
>
> This patch splits it into two, generalising the core of the locking code
> into a new libxl__lock_file() function
On Thu, Jan 30, 2020 at 05:47:03PM +0100, Jan Beulich wrote:
> Don't silently ignore the upper 32 bits.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On Wed, Jan 29, 2020 at 03:19:05PM +0100, Jan Beulich wrote:
> On 17.01.2020 11:53, Anthony PERARD wrote:
> > +# Handle objects in subdirs
> > +#
> > ---
> > +# o if we encounter foo/ in $(obj-y), replace it by foo/built_in.o
On 30.01.2020 17:45, PGNet Dev wrote:
>> I'd like to request you adding the dom0 kernel boot parameters, too:
>> debug initcall_debug
>
> added
>
> with current config,
>
> [config.1]
> options=dom0_max_vcpus=4 dom0_mem=4016M,max:4096M console_to_ring
> conring_size=20480k
Vladimir Sementsov-Ogievskiy writes:
> Markus, what about this? Should I respin?
I still haven't looked at this, must be frustrating for you, sorry!
I've been under water ever since my Christmas vacation... If you rather
want me to look at a v7 that addresses the review comments from others,
Don't silently ignore the upper 32 bits.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/pmtimer.c
+++ b/xen/arch/x86/hvm/pmtimer.c
@@ -313,9 +313,9 @@ static int acpi_load(struct domain *d, h
HVM_REGISTER_SAVE_RESTORE(PMTIMER, acpi_save, acpi_load,
1,
On Thu, Jan 30, 2020 at 03:44:53PM +0100, Jan Beulich wrote:
> There's no need to have twice almost the same rule. Simply add the extra
> -DEFI to AFLAGS for the EFI variant, and specify both targets for the
> then single rule.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
> 'xl devd' should add the backend interfaces (vifX.Y) to the bridge if
> properly configured, as it should be calling the hotplug scripts to do that.
Yes, running ' xl devd' in the driver domain before launching the DomU, solved
the bridge issue. Thanks a lot.
So, for the people who end up
On 30.01.2020 17:32, Durrant, Paul wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 30 January 2020 16:29
>> To: Durrant, Paul
>> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
>> ; Wei Liu ; Roger Pau Monné
>> ; George Dunlap ; Ian
>> Jackson ; Julien Grall ; Konrad
>>
> -Original Message-
> From: Jan Beulich
> Sent: 30 January 2020 16:29
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
> ; George Dunlap ; Ian
> Jackson ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Tim Deegan
>
On 30.01.2020 15:57, Paul Durrant wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -218,7 +218,7 @@ void dump_pageframe_info(struct domain *d)
>
> printk("Memory pages belonging to domain %u:\n", d->domain_id);
>
> -if ( d->tot_pages >= 10 && d->is_dying <
flight 146598 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146598/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On 30.01.2020 15:57, Paul Durrant wrote:
> Currently it is unsafe to assign a domheap page allocated with
> MEMF_no_refcount to a domain because the domain't 'tot_pages' will not
> be incremented, but will be decrement when the page is freed (since
> free_domheap_pages() has no way of telling that
From: David Woodhouse
For live update to work, it will need a region of memory that can be
given to the boot allocator while it parses the state information from
the previous Xen and works out which of the other pages of memory it
can consume.
Reserve that like the crashdump region, and accept
From: David Woodhouse
It's about to become optional as __start_xen() grows a different path
for live update, so move it out of the way.
Signed-off-by: David Woodhouse
---
xen/arch/x86/setup.c | 173 +++
1 file changed, 94 insertions(+), 79 deletions(-)
From: Wei Liu
We want to move vm_init, which calls vm_init_type under the hood, to
early boot stage. Add a path to get page from boot allocator instead.
Add an emacs block to that file while I was there.
Signed-off-by: Wei Liu
---
xen/common/vmap.c | 22 +++---
1 file
From: David Woodhouse
Signed-off-by: David Woodhouse
---
xen/common/lu/stream.c | 50 ++
xen/include/xen/lu.h | 5 +
2 files changed, 55 insertions(+)
diff --git a/xen/common/lu/stream.c b/xen/common/lu/stream.c
index 8c44a4eb37..2ee870e80a
From: David Woodhouse
Signed-off-by: David Woodhouse
---
tools/libxc/xc_sr_common.c| 20 ++--
tools/libxc/xc_sr_common_x86.c| 4 +-
tools/libxc/xc_sr_restore.c | 2 +-
tools/libxc/xc_sr_restore_x86_hvm.c | 4 +-
tools/libxc/xc_sr_restore_x86_pv.c| 8
From: David Woodhouse
Signed-off-by: David Woodhouse
---
xen/common/kimage.c | 34 ++
xen/include/xen/kimage.h | 3 +++
xen/include/xen/lu.h | 3 +++
3 files changed, 40 insertions(+)
diff --git a/xen/common/kimage.c b/xen/common/kimage.c
index
From: David Woodhouse
This is identical to the default case... for now.
Signed-off-by: David Woodhouse
---
xen/common/kexec.c | 18 ++
xen/include/public/kexec.h | 12
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/xen/common/kexec.c
From: David Woodhouse
This currently only iterates over the records and prints the version of
Xen that we're live updating from.
In the fullness of time, it will also reserve the pages passed over as
M2P as well as the pages belonging to preserved domains.
Signed-off-by: David Woodhouse
---
From: David Woodhouse
---
xen/common/kexec.c | 6 +
xen/common/lu/Makefile | 2 +-
xen/common/lu/save.c | 56 ++
xen/include/xen/lu.h | 3 +++
4 files changed, 66 insertions(+), 1 deletion(-)
create mode 100644 xen/common/lu/save.c
diff
From: David Woodhouse
With this we are fairly much done hacking up __start_xen() to support
live update. The live update functions themselves are still stubs,
but now we can start populating those with actual save/restore of
domain information.
Signed-off-by: David Woodhouse
---
From: David Woodhouse
Signed-off-by: David Woodhouse
---
xen/common/Makefile| 1 +
xen/common/lu/Makefile | 1 +
xen/common/lu/stream.c | 135 +
xen/include/xen/lu.h | 29 +
4 files changed, 166 insertions(+)
create mode 100644
From: David Woodhouse
Signed-off-by: David Woodhouse
---
xen/common/vmap.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/xen/common/vmap.c b/xen/common/vmap.c
index 37922f735b..8343460794 100644
--- a/xen/common/vmap.c
+++ b/xen/common/vmap.c
@@
From: David Woodhouse
We would like to be able to use vmap() to map the live update data, and
we need to do a first pass of the live update data before we prime the
heap because we need to know which pages need to be preserved.
Signed-off-by: David Woodhouse
---
xen/arch/x86/setup.c | 8
From: David Woodhouse
This allows a single page-aligned physical address to be written to
the current destination, intended to pass the location of the live
update data stream from one Xen to the next.
Signed-off-by: David Woodhouse
---
xen/arch/x86/x86_64/kexec_reloc.S | 9 -
From: David Woodhouse
Signed-off-by: David Woodhouse
---
xen/common/lu/save.c | 13 -
xen/include/public/migration_stream.h | 9 +
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/xen/common/lu/save.c b/xen/common/lu/save.c
index
From: David Woodhouse
Signed-off-by: David Woodhouse
---
xen/common/page_alloc.c | 83 +++--
1 file changed, 80 insertions(+), 3 deletions(-)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index a74bf02559..4ada4412dd 100644
---
From: David Woodhouse
This allows kexec userspace to tell the next Xen where the range is,
on its command line.
Signed-off-by: David Woodhouse
---
xen/arch/x86/machine_kexec.c | 13 ++---
xen/include/public/kexec.h | 1 +
2 files changed, 11 insertions(+), 3 deletions(-)
diff
From: David Woodhouse
Set 'e' correctly to reflect the location that Xen is actually relocated
to from its default 2MiB location. Not 2MiB below that.
This is only vaguely a bug fix. The "missing" 2MiB would have been used
in the end, and fed to the allocator. It's just that other things don't
From: David Woodhouse
Remove a ternary operator that made my brain hurt and replace it with
something simpler that makes it clearer that the >= mbi->mods_count
is because of what find_first_bit() returns when it doesn't find
anything. Just have a simple condition to set initrdidx to zero in
that
From: David Woodhouse
Signed-off-by: David Woodhouse
---
xen/arch/x86/setup.c | 35 +--
xen/common/lu/stream.c | 34 ++
xen/include/xen/lu.h | 2 ++
3 files changed, 69 insertions(+), 2 deletions(-)
diff --git
From: David Woodhouse
Signed-off-by: David Woodhouse
---
docs/specs/libxc-migration-stream.pandoc | 19 +-
docs/specs/live-update-handover.pandoc | 371 +++
2 files changed, 388 insertions(+), 2 deletions(-)
create mode 100644 docs/specs/live-update-handover.pandoc
flight 146588 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146588/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121
From: David Woodhouse
The live update handover requires that a region of memory be reserved
for the new Xen to use in its boot allocator. The original Xen may use
that memory but not for any pages which are mapped to domains, or which
would need to be preserved across the live update for any
Now with added documentation:
http://david.woodhou.se/live-update-handover.pdf
v1:
Reserve a contiguous region of memory which can be safely used by the
boot allocator in the new Xen, before the live update data stream has
been processed and thus before the locations of all the other pages
On Thu, Jan 30, 2020 at 04:25:44PM +0100, Roger Pau Monné wrote:
> On Thu, Jan 30, 2020 at 03:03:03PM +, Wei Liu wrote:
> > On Thu, Jan 30, 2020 at 03:47:04PM +0100, Roger Pau Monné wrote:
> > > On Thu, Jan 30, 2020 at 02:25:26PM +, Wei Liu wrote:
> > > > On Thu, Jan 30, 2020 at 03:22:01PM
I am deeply shocked by the news. I would like to express my deepest condolences
to Lars' family and friends. Lars has always been a very open-minded and
supportive person. He was definitely a big win for the Xen Project and its
community. I feel honored to have had the chance to work with him.
On 30.01.2020 10:18, Roger Pau Monné wrote:
> On Thu, Jan 30, 2020 at 10:12:39AM +0100, Jan Beulich wrote:
>> On 30.01.2020 04:56, osstest service owner wrote:
>>> flight 146578 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/146578/
>>>
>>> Regressions :-(
>>>
>>>
On Thu, Jan 30, 2020 at 03:03:03PM +, Wei Liu wrote:
> On Thu, Jan 30, 2020 at 03:47:04PM +0100, Roger Pau Monné wrote:
> > On Thu, Jan 30, 2020 at 02:25:26PM +, Wei Liu wrote:
> > > On Thu, Jan 30, 2020 at 03:22:01PM +0100, Roger Pau Monné wrote:
> > > > On Thu, Jan 30, 2020 at 12:39:20PM
flight 146589 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146589/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
On 30.01.2020 15:47, Andrew Cooper wrote:
> On 30/01/2020 14:44, Jan Beulich wrote:
>> There's no need to have twice almost the same rule. Simply add the extra
>> -DEFI to AFLAGS for the EFI variant, and specify both targets for the
>> then single rule.
>>
>> Signed-off-by: Jan Beulich
>>
>> ---
flight 146584 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146584/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 17 guest-start.2 fail REGR.
vs. 146563
Volodymyr Babchuk writes:
Oleksandr,
[...]
>> diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c
>> b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
>> index c21d2d7..411fc0f 100644
>> --- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c
>> +++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
>> @@ -702,7
flight 146597 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146597/
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
Hi Oleksandr,
Oleksandr writes:
[...]
>>> +
>>> +/*
>>> + * We need to prevent the use cases where devices which use the same
>>> + * micro-TLB are assigned to different Xen domains (micro-TLB cannot be
>>> + * shared between multiple Xen domains, since it points to the context
On Thu, Jan 30, 2020 at 03:47:04PM +0100, Roger Pau Monné wrote:
> On Thu, Jan 30, 2020 at 02:25:26PM +, Wei Liu wrote:
> > On Thu, Jan 30, 2020 at 03:22:01PM +0100, Roger Pau Monné wrote:
> > > On Thu, Jan 30, 2020 at 12:39:20PM +, Wei Liu wrote:
> > > > On Thu, Jan 30, 2020 at 01:32:26PM
Paul Durrant (4):
x86 / vmx: move teardown from domain_destroy()...
add a domain_tot_pages() helper function
mm: make pages allocated with MEMF_no_refcount safe to assign
x86 / vmx: use a MEMF_no_refcount domheap page for
APIC_DEFAULT_PHYS_BASE
xen/arch/x86/domain.c | 2 +-
vmx_alloc_vlapic_mapping() currently contains some very odd looking code
that allocates a MEMF_no_owner domheap page and then shares with the guest
as if it were a xenheap page. This then requires vmx_free_vlapic_mapping()
to call a special function in the mm code: free_shared_domheap_page().
By
Currently it is unsafe to assign a domheap page allocated with
MEMF_no_refcount to a domain because the domain't 'tot_pages' will not
be incremented, but will be decrement when the page is freed (since
free_domheap_pages() has no way of telling that the increment was skipped).
This patch
... to domain_relinquish_resources().
The teardown code frees the APICv page. This does not need to be done late
so do it in domain_relinquish_resources() rather than domain_destroy().
Signed-off-by: Paul Durrant
---
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei
This patch adds a new domain_tot_pages() inline helper function into
sched.h, which will be needed by a subsequent patch.
No functional change.
NOTE: While modifying the comment for 'tot_pages' in sched.h this patch
makes some cosmetic fixes to surrounding comments.
Suggested-by: Jan
I'm very sad to inform you that Lars Kurth passed away earlier this
week. Many of us regarded Lars as a personal friend, and his loss is a
great loss to the Xen Project.
We plan to have a tribute to Lars on the XenProject blog in the near
future. Those who are attending FOSDEM may wish to
flight 146595 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146595/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On 30/01/2020 14:44, Jan Beulich wrote:
> There's no need to have twice almost the same rule. Simply add the extra
> -DEFI to AFLAGS for the EFI variant, and specify both targets for the
> then single rule.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/Makefile
> +++
On Thu, Jan 30, 2020 at 02:25:26PM +, Wei Liu wrote:
> On Thu, Jan 30, 2020 at 03:22:01PM +0100, Roger Pau Monné wrote:
> > On Thu, Jan 30, 2020 at 12:39:20PM +, Wei Liu wrote:
> > > On Thu, Jan 30, 2020 at 01:32:26PM +0100, Roger Pau Monné wrote:
> > > > On Thu, Jan 30, 2020 at 12:28:36PM
There's no need to have twice almost the same rule. Simply add the extra
-DEFI to AFLAGS for the EFI variant, and specify both targets for the
then single rule.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -241,15 +241,12 @@
Hi Oleksandr,
Hi Volodymyr
@@ -434,19 +435,45 @@ static void ipmmu_tlb_invalidate(struct ipmmu_vmsa_domain
*domain)
}
/* Enable MMU translation for the micro-TLB. */
-static void ipmmu_utlb_enable(struct ipmmu_vmsa_domain *domain,
- unsigned int utlb)
On 17.01.2020 11:53, Anthony PERARD wrote:
> Instead of generating the CFLAGS in Rules.mk everytime we enter a new
> subdirectory, we are going to generate most of them a single time, and
> export the result in the environment so that Rules.mk can use it. The
> only flags left to generates are
On Thu, Jan 30, 2020 at 03:22:01PM +0100, Roger Pau Monné wrote:
> On Thu, Jan 30, 2020 at 12:39:20PM +, Wei Liu wrote:
> > On Thu, Jan 30, 2020 at 01:32:26PM +0100, Roger Pau Monné wrote:
> > > On Thu, Jan 30, 2020 at 12:28:36PM +, Wei Liu wrote:
> > > > On Thu, Jan 30, 2020 at 01:08:07PM
On Thu, Jan 30, 2020 at 12:39:20PM +, Wei Liu wrote:
> On Thu, Jan 30, 2020 at 01:32:26PM +0100, Roger Pau Monné wrote:
> > On Thu, Jan 30, 2020 at 12:28:36PM +, Wei Liu wrote:
> > > On Thu, Jan 30, 2020 at 01:08:07PM +0100, Roger Pau Monné wrote:
> > > >
> > > > > +}
> > > > > +
> > > >
On Thu, Jan 30, 2020 at 01:26:55PM +0100, Roger Pau Monné wrote:
> On Wed, Jan 29, 2020 at 08:20:32PM +, Wei Liu wrote:
> > Hyper-V's input / output argument must be 8 bytes aligned an not cross
> > page boundary. One way to satisfy those requirements is to use percpu
> > page.
> >
> > For
On Thu, Jan 30, 2020 at 01:42:29PM +0100, Roger Pau Monné wrote:
> On Wed, Jan 29, 2020 at 08:20:34PM +, Wei Liu wrote:
> > VP assist page is rather important as we need to toggle some bits in it
> > for efficient nested virtualisation.
> >
> > Signed-off-by: Wei Liu
> > ---
> > v5:
> > 1.
On Thu, Jan 30, 2020 at 10:34:29AM +, Durrant, Paul wrote:
> > +
> > +val = (virt_to_mfn(mapping) << HV_HYP_PAGE_SHIFT)
> > +| HV_X64_MSR_VP_ASSIST_PAGE_ENABLE;
>
> Perhaps it would be neater to put the viridian_page_msr union into
> hyperv-tlfs.h and then use that.
Done. Now
On 17.01.2020 11:53, Anthony PERARD wrote:
> We are going to want $(CFLAGS) to be static and never change during
> the build, so introduce new variables that can be use to change the
> flags of a single target or of a whole directory.
I'm again struggling with the "why": What problem is there
On 21.01.2020 14:59, Anthony PERARD wrote:
> The XEN_BUILD_EFI tests in arch/x86/Makefile was filtering out
> CFLAGS-y, but according to dd40177c1bc8 ("x86-64/EFI: add CFLAGS to
> check compile"), it was done to filter out -MF. XEN_CFLAGS doesn't
> have those flags anymore, so no filtering is
On 17.01.2020 11:53, Anthony PERARD wrote:
> We would like to calculate CFLAGS once and before calling Rules.mk,
> so the variable CFLAGS needs to have the same value across the whole
> build. Thus we need a new variable where some flags can change
> depending on the target name.
>
> Both the
On Thu, Jan 30, 2020 at 11:01:29AM +0100, Roger Pau Monné wrote:
> On Wed, Jan 29, 2020 at 08:20:24PM +, Wei Liu wrote:
> > We want to be able to handle AP setup error in the upper layer.
>
> Thanks, some comments below.
>
> >
> > Signed-off-by: Wei Liu
> > ---
> >
On 1/27/20 3:18 AM, sjp...@amazon.com wrote:
> From: SeongJae Park
>
> Granting pages consumes backend system memory. In systems configured
> with insufficient spare memory for those pages, it can cause a memory
> pressure situation. However, finding the optimal amount of the spare
> memory
On 30/01/2020 12:44, Anthony PERARD wrote:
> On Thu, Jan 30, 2020 at 10:12:51AM +0100, Roger Pau Monné wrote:
>> On Wed, Jan 29, 2020 at 12:12:34PM +, Anthony PERARD wrote:
>>> + Parameters.domid = DOMID_SELF;
>>> + Parameters.gpfn = (UINTN) PagePtr >> EFI_PAGE_SHIFT;
>>> + ReturnCode =
At this moment a guest can call vmfunc to change the altp2m view. This
should be limited in order to avoid any unwanted view switch.
The new xc_altp2m_set_visibility() solves this by making views invisible
to vmfunc.
This is done by having a separate arch.altp2m_working_eptp that is
populated and
On 17.01.2020 11:53, Anthony PERARD wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -49,7 +49,71 @@ default: build
> .PHONY: dist
> dist: install
>
> -build install:: include/config/auto.conf
> +
> +ifndef root-make-done
> +# section to run before calling Rules.mk, but only once.
> +#
>
Hi,
we use SLES12 with kernel-default-4.12.14-95.45.1.x86_64 and
xen-4.11.3_02-2.20.1.x86_64
The dump kernel doesn't start after "echo c > /proc/sysrq_trigger".
Last messages on console are:
[ 385.717532] Kernel panic - not syncing: Fatal exception
[ 385.734565] Kernel Offset: disabled
(XEN)
On Thu, Jan 30, 2020 at 10:12:51AM +0100, Roger Pau Monné wrote:
> On Wed, Jan 29, 2020 at 12:12:34PM +, Anthony PERARD wrote:
> > + Parameters.domid = DOMID_SELF;
> > + Parameters.gpfn = (UINTN) PagePtr >> EFI_PAGE_SHIFT;
> > + ReturnCode = XenHypercallMemoryOp (XENMEM_remove_from_physmap,
On Wed, Jan 29, 2020 at 08:20:34PM +, Wei Liu wrote:
> VP assist page is rather important as we need to toggle some bits in it
> for efficient nested virtualisation.
>
> Signed-off-by: Wei Liu
> ---
> v5:
> 1. Deal with error properly instead of always panicking
> 2. Swap percpu variables
On Thu, Jan 30, 2020 at 01:32:26PM +0100, Roger Pau Monné wrote:
> On Thu, Jan 30, 2020 at 12:28:36PM +, Wei Liu wrote:
> > On Thu, Jan 30, 2020 at 01:08:07PM +0100, Roger Pau Monné wrote:
> > >
> > > > +}
> > > > +
> > > > /*
> > > > * Local variables:
> > > > * mode: C
> > > > diff
1 - 100 of 148 matches
Mail list logo
