On 01.07.20 14:07, Oleksandr Andrushchenko wrote:
On 7/1/20 1:46 PM, Jürgen Groß wrote:
On 01.07.20 09:19, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
1. Add protocol version as an integer
Version string, which is in fact an integer, is hard to handle in the
code that suppor
> -Original Message-
> From: Jan Beulich
> Sent: 01 July 2020 11:23
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Julien Grall ; Wei Liu
> ; Stefano
> Stabellini ; Roger Pau Monné ;
> Paul Durrant
>
> Subject: [PATCH v2 0/7] x86: compat he
On 02.07.2020 09:34, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 01 July 2020 11:23
>> To: xen-devel@lists.xenproject.org
>> Cc: Andrew Cooper ; George Dunlap
>> ; Ian
>> Jackson ; Julien Grall ; Wei Liu
>> ; Stefano
>> Stabellini ; Roger Pau Monné ;
>> Paul
On 29.06.2020 18:30, Anthony PERARD wrote:
> On Fri, Jun 26, 2020 at 05:02:30PM +0200, Jan Beulich wrote:
>> While I've been running into an issue here only because of an additional
>> local change I'm carrying, to be able to override just the compiler in
>> $(XEN_ROOT)/.config (rather than the who
> -Original Message-
> From: Jan Beulich
> Sent: 02 July 2020 08:45
> To: Paul Durrant
> Cc: Anthony PERARD ;
> xen-devel@lists.xenproject.org; Andrew Cooper
> ; George Dunlap ; Ian
> Jackson
> ; Julien Grall ; Wei Liu
> ; Stefano Stabellini
>
> Subject: Ping: [PATCH] build: tweak var
On 7/2/20 10:20 AM, Jürgen Groß wrote:
> On 01.07.20 14:07, Oleksandr Andrushchenko wrote:
>> On 7/1/20 1:46 PM, Jürgen Groß wrote:
>>> On 01.07.20 09:19, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
1. Add protocol version as an integer
Version string, wh
On Wed, Jul 01, 2020 at 10:42:55PM +0100, Andrew Cooper wrote:
> On 30/06/2020 13:33, Michał Leszczyński wrote:
> > diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> > index ca94c2bedc..b73d824357 100644
> > --- a/xen/arch/x86/hvm/vmx/vmcs.c
> > +++ b/xen/arch/x86/hvm/vmx/vmc
On Wed, Jul 01, 2020 at 01:06:46PM +0200, Juergen Gross wrote:
> The long term plan has been to replace Xen PV guests by PVH. The first
> victim of that plan are now 32-bit PV guests, as those are used only
> rather seldom these days. Xen on x86 requires 64-bit support and with
> Grub2 now supporti
On 01.07.2020 20:09, Julien Grall wrote:
> On 01/07/2020 19:06, Andrew Cooper wrote:
>> On 01/07/2020 19:02, Julien Grall wrote:
>>> On 01/07/2020 18:26, Andrew Cooper wrote:
For the sake of what is literally just one byte in common code, I stand
my original suggestion of this being a com
On 02.07.2020 10:10, Roger Pau Monné wrote:
> On Wed, Jul 01, 2020 at 10:42:55PM +0100, Andrew Cooper wrote:
>> On 30/06/2020 13:33, Michał Leszczyński wrote:
>>> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
>>> index ca94c2bedc..b73d824357 100644
>>> --- a/xen/arch/x86/hv
On 02.07.20 09:59, Oleksandr Andrushchenko wrote:
On 7/2/20 10:20 AM, Jürgen Groß wrote:
On 01.07.20 14:07, Oleksandr Andrushchenko wrote:
On 7/1/20 1:46 PM, Jürgen Groß wrote:
On 01.07.20 09:19, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
1. Add protocol version as an int
Hi Jan,
On 02/07/2020 09:29, Jan Beulich wrote:
On 01.07.2020 20:09, Julien Grall wrote:
On 01/07/2020 19:06, Andrew Cooper wrote:
On 01/07/2020 19:02, Julien Grall wrote:
On 01/07/2020 18:26, Andrew Cooper wrote:
For the sake of what is literally just one byte in common code, I stand
my ori
On 02.07.2020 10:42, Julien Grall wrote:
> On 02/07/2020 09:29, Jan Beulich wrote:
>> I'm with Andrew here, fwiw, as long as the little bit of code that
>> is actually put in common/ or include/xen/ doesn't imply arbitrary
>> restrictions on acceptable values.
> Well yes the code is simple. However
On 02/07/2020 09:50, Jan Beulich wrote:
On 02.07.2020 10:42, Julien Grall wrote:
On 02/07/2020 09:29, Jan Beulich wrote:
I'm with Andrew here, fwiw, as long as the little bit of code that
is actually put in common/ or include/xen/ doesn't imply arbitrary
restrictions on acceptable values.
W
On Tue, Jun 30, 2020 at 02:33:46PM +0200, Michał Leszczyński wrote:
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 59bdc28c89..7b8289d436 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -92,6 +92,7 @@ struct xen_domctl_createdoma
On 02.07.2020 10:54, Julien Grall wrote:
>
>
> On 02/07/2020 09:50, Jan Beulich wrote:
>> On 02.07.2020 10:42, Julien Grall wrote:
>>> On 02/07/2020 09:29, Jan Beulich wrote:
I'm with Andrew here, fwiw, as long as the little bit of code that
is actually put in common/ or include/xen/ do
Hi,
On 02/07/2020 10:18, Jan Beulich wrote:
On 02.07.2020 10:54, Julien Grall wrote:
On 02/07/2020 09:50, Jan Beulich wrote:
On 02.07.2020 10:42, Julien Grall wrote:
On 02/07/2020 09:29, Jan Beulich wrote:
I'm with Andrew here, fwiw, as long as the little bit of code that
is actually put i
Hi Michał,
On Tue, Jun 30, 2020 at 02:33:46PM +0200, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Allow to specify the size of per-vCPU trace buffer upon
> domain creation. This is zero by default (meaning: not enabled).
>
> Signed-off-by: Michal Leszczynski
> ---
>
> diff --git a
flight 151516 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151516/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim12 guest-start fail never pass
test-amd64-amd64-libvirt 13 migrate
Andy Lutomirski writes:
> On Wed, Jul 1, 2020 at 8:42 AM Brian Gerst wrote:
> > On Fri, Jun 26, 2020 at 1:30 PM Andy Lutomirski wrote:
>> >
>> > The SYSENTER frame setup was nonsense. It worked by accident
>> > because the normal code into which the Xen asm jumped
>> > (entry_SYSENTER_32/compat
Hey all,
Rather than holding the community call this month, I think people should submit
design sessions for topics they want to discuss:
https://design-sessions.xenproject.org
We’ll pick up again in August.
-George
flight 151535 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151535/
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 1
flight 151513 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151513/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
Tests which are fa
On 02.07.2020 11:57, Julien Grall wrote:
> Hi,
>
> On 02/07/2020 10:18, Jan Beulich wrote:
>> On 02.07.2020 10:54, Julien Grall wrote:
>>>
>>>
>>> On 02/07/2020 09:50, Jan Beulich wrote:
On 02.07.2020 10:42, Julien Grall wrote:
> On 02/07/2020 09:29, Jan Beulich wrote:
>> I'm with And
Hi,
On 02/07/2020 14:30, Jan Beulich wrote:
On 02.07.2020 11:57, Julien Grall wrote:
Hi,
On 02/07/2020 10:18, Jan Beulich wrote:
On 02.07.2020 10:54, Julien Grall wrote:
On 02/07/2020 09:50, Jan Beulich wrote:
On 02.07.2020 10:42, Julien Grall wrote:
On 02/07/2020 09:29, Jan Beulich wrot
On 02.07.2020 16:14, Julien Grall wrote:
> Hi,
>
> On 02/07/2020 14:30, Jan Beulich wrote:
>> On 02.07.2020 11:57, Julien Grall wrote:
>>> Hi,
>>>
>>> On 02/07/2020 10:18, Jan Beulich wrote:
On 02.07.2020 10:54, Julien Grall wrote:
>
>
> On 02/07/2020 09:50, Jan Beulich wrote:
>>>
From: Colin Ian King
The variable act is being initialized with a value that is
never read and it is being updated later with a new value. The
initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/net/xen-netfront.c | 2 +
On Thu, Jun 04, 2020 at 02:31:41PM -0400, Paolo Bonzini wrote:
> From: Anthony PERARD
>
> Xen PCI passthrough support may not be available and thus the global
> variable "has_igd_gfx_passthru" might be compiled out. Common code
> should not access it in that case.
>
> Unfortunately, we can't use
On 02/07/2020 15:17, Jan Beulich wrote:
On 02.07.2020 16:14, Julien Grall wrote:
On 02/07/2020 14:30, Jan Beulich wrote:
On 02.07.2020 11:57, Julien Grall wrote:
On 02/07/2020 10:18, Jan Beulich wrote:
On 02.07.2020 10:54, Julien Grall wrote:
On 02/07/2020 09:50, Jan Beulich wrote:
On 02
flight 151527 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151527/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR.
vs. 151496
test-amd64-i38
On Wed, Jul 1, 2020 at 7:07 AM Juergen Gross wrote:
>
> The long term plan has been to replace Xen PV guests by PVH. The first
> victim of that plan are now 32-bit PV guests, as those are used only
> rather seldom these days. Xen on x86 requires 64-bit support and with
> Grub2 now supporting PVH o
> -Original Message-
> From: Xen-devel On Behalf Of Anthony
> PERARD
> Sent: 02 July 2020 15:26
> To: Paul Durrant
Emails to this address are probably going to /dev/null by now :-)
> Cc: xen-devel@lists.xenproject.org; Roger Pau Monné
> Subject: Re: [PATCH v5] xen: fix build without p
On 30/06/2020 13:33, Michał Leszczyński wrote:
> diff --git a/tools/proctrace/COPYING b/tools/proctrace/COPYING
> new file mode 100644
> index 00..c0a841112c
> --- /dev/null
> +++ b/tools/proctrace/COPYING
The top-level COPYING file is GPL2. There shouldn't be any need to
include a second
On 02.07.20 16:48, Brian Gerst wrote:
On Wed, Jul 1, 2020 at 7:07 AM Juergen Gross wrote:
The long term plan has been to replace Xen PV guests by PVH. The first
victim of that plan are now 32-bit PV guests, as those are used only
rather seldom these days. Xen on x86 requires 64-bit support and
- 2 lip 2020 o 11:00, Roger Pau Monné roger@citrix.com napisał(a):
> On Tue, Jun 30, 2020 at 02:33:46PM +0200, Michał Leszczyński wrote:
>> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
>> index 59bdc28c89..7b8289d436 100644
>> --- a/xen/include/public/domctl.h
>>
Hello,
On 02/07/2020 02:41, jinchen wrote:
Hello xen experts:
Is there any way to save xen and dom0 core dump log when xen or dom0
crash on ARM64 platform?
Usually all the crash stack trace (Xen and Dom0) should be output on the
Xen Console.
?0?2 ?0?2 I find that the kdump seems can't?0
Hi Wei,
On 26/06/2020 12:08, Wei Liu wrote:
On Thu, Jun 11, 2020 at 03:57:37PM +0100, Julien Grall wrote:
Hi all,
kexec-tools has an option to load dynamically libxenctlr.so (not .so.4.x)
(see [1]).
Given that the library has never been considered stable, it is probably a
disaster that is wai
From: Munehisa Kamata
Guest hibernation is different from xen suspend/resume/live migration.
Xen save/restore does not use pm_ops as is needed by guest hibernation.
Hibernation in guest follows ACPI path and is guest inititated , the
hibernation image is saved within guest as compared to later mo
Hello,
This series fixes PM hibernation for hvm guests running on xen hypervisor.
The running guest could now be hibernated and resumed successfully at a
later time. The fixes for PM hibernation are added to block and
network device drivers i.e xen-blkfront and xen-netfront. Any other driver
that n
Introduce a small function which re-uses shared page's PA allocated
during guest initialization time in reserve_shared_info() and not
allocate new page during resume flow.
It also does the mapping of shared_info_page by calling
xen_hvm_init_shared_info() to use the function.
Changelog:
v1->v2: Re
From: Munehisa Kamata
Add freeze, thaw and restore callbacks for PM suspend and hibernation
support. The freeze handler simply disconnects the frotnend from the
backend and frees resources associated with queues after disabling the
net_device from the system. The restore handler just changes the
From: Munehisa Kamata
S4 power transisiton states are much different than xen
suspend/resume. Former is visible to the guest and frontend drivers should
be aware of the state transistions and should be able to take appropriate
actions when needed. In transition to S4 we need to make sure that at
Introduce wrappers for save/restore xen_sched_clock_offset to be
used by PM hibernation code to avoid system instability during resume.
Signed-off-by: Anchal Agarwal
---
arch/x86/xen/time.c| 15 +--
arch/x86/xen/xen-ops.h | 2 ++
2 files changed, 15 insertions(+), 2 deletions(-)
Save/restore steal times in syscore suspend/resume during PM
hibernation. Commit '5e25f5db6abb9: ("xen/time: do not
decrease steal time after live migration on xen")' fixes xen
guest steal time handling during migration. A similar issue is seen
during PM hibernation.
Currently, steal time accountin
Save/restore xen_sched_clock_offset in syscore suspend/resume during PM
hibernation. Commit '867cefb4cb1012: ("xen: Fix x86 sched_clock() interface
for xen")' fixes xen guest time handling during migration. A similar issue
is seen during PM hibernation when system runs CPU intensive workload.
Post
From: Munehisa Kamata
Since commit b3e96c0c7562 ("xen: use freeze/restore/thaw PM events for
suspend/resume/chkpt"), xenbus uses PMSG_FREEZE, PMSG_THAW and
PMSG_RESTORE events for Xen suspend. However, they're actually assigned
to xenbus_dev_suspend(), xenbus_dev_cancel() and xenbus_dev_resume()
On Tue, Jun 30, Michael Young wrote:
> I get the following errors when trying to build xen-4.14.0-rc4
This happens to work for me.
Olaf
---
tools/debugger/kdd/kdd.c | 8
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/tools/debugger/kdd/kdd.c
+++ b/tools/debugger/kdd/kdd.c
@@ -
flight 151518 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151518/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 15106
flight 151532 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151532/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c8edb70945099fd35a0997d3f3db105efc144e13
baseline version:
ovmf 00217f1919270007d7a91
- 2 lip 2020 o 16:31, Julien Grall jul...@xen.org napisał(a):
> On 02/07/2020 15:17, Jan Beulich wrote:
>> On 02.07.2020 16:14, Julien Grall wrote:
>>> On 02/07/2020 14:30, Jan Beulich wrote:
On 02.07.2020 11:57, Julien Grall wrote:
> On 02/07/2020 10:18, Jan Beulich wrote:
>> On
- 2 lip 2020 o 10:34, Jan Beulich jbeul...@suse.com napisał(a):
> On 02.07.2020 10:10, Roger Pau Monné wrote:
>> On Wed, Jul 01, 2020 at 10:42:55PM +0100, Andrew Cooper wrote:
>>> On 30/06/2020 13:33, Michał Leszczyński wrote:
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vm
On 7/1/20 8:16 AM, Juergen Gross wrote:
> xenbus_map_ring_valloc() and its sub-functions are putting quite large
> structs and arrays on the stack. This is problematic at runtime, but
> might also result in build failures (e.g. with clang due to the option
> -Werror,-Wframe-larger-than=... used).
>
flight 151528 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151528/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail REGR.
vs. 151506
Tests w
From: Colin King
Date: Thu, 2 Jul 2020 15:22:23 +0100
> From: Colin Ian King
>
> The variable act is being initialized with a value that is
> never read and it is being updated later with a new value. The
> initialization is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value
On 7/1/20 7:06 AM, Juergen Gross wrote:
> Xen is requiring 64-bit machines today and since Xen 4.14 it can be
> built without 32-bit PV guest support. There is no need to carry the
> burden of 32-bit PV guest support in the kernel any longer, as new
> guests can be either HVM or PVH, or they can us
On 02/07/2020 23:59, Boris Ostrovsky wrote:
> On 7/1/20 7:06 AM, Juergen Gross wrote:
>>
>> -#ifdef CONFIG_X86_PAE
>> -static void xen_set_pte_atomic(pte_t *ptep, pte_t pte)
>> -{
>> -trace_xen_mmu_set_pte_atomic(ptep, pte);
>> -__xen_set_pte(ptep, pte);
>
> Probably not for this series b
On 7/2/20 7:24 PM, Andrew Cooper wrote:
> On 02/07/2020 23:59, Boris Ostrovsky wrote:
>> On 7/1/20 7:06 AM, Juergen Gross wrote:
>>>
>>> -#ifdef CONFIG_X86_PAE
>>> -static void xen_set_pte_atomic(pte_t *ptep, pte_t pte)
>>> -{
>>> - trace_xen_mmu_set_pte_atomic(ptep, pte);
>>> - __xen_set_pte
flight 151544 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151544/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 149875
test-armhf-armhf-libvirt-r
flight 151540 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151540/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
Regressions which
flight 151550 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151550/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0622a7b1b203ad4ab1675533e958792fc1afc12b
baseline version:
ovmf c8edb70945099fd35a099
On 03.07.20 00:59, Boris Ostrovsky wrote:
On 7/1/20 7:06 AM, Juergen Gross wrote:
Xen is requiring 64-bit machines today and since Xen 4.14 it can be
built without 32-bit PV guest support. There is no need to carry the
burden of 32-bit PV guest support in the kernel any longer, as new
guests can
Thank you for your reply!
On 02/07/2020 02:41, jinchen wrote:
>> Hello xen experts:
>>
>> Is there any way to save xen and dom0 core dump log when xen or dom0
>> crash on ARM64 platform?
>Usually all the crash stack trace (Xen and Dom0) should be output on the
>Xen Console.
But if I don't c
62 matches
Mail list logo
