On 02.04.2020 19:55, Andrew Cooper wrote:
> On 13/03/2020 09:26, Jan Beulich wrote:
>> All CPUs get an equal setting of EOI broadcast suppression; no need to
>> log one message per CPU, even if it's only in verbose APIC mode.
>>
>> Only the BSP is eligible to possibly get ExtINT enabled; no need to
On 02.04.2020 21:49, Andrew Cooper wrote:
> On 02/04/2020 08:46, Jan Beulich wrote:
>> In preparation for the addition of VMASST_TYPE_runstate_update_flag
>> commit 72c538cca957 ("arm: add support for vm_assist hypercall") enabled
>> the hypercall for Arm. I consider it not logical that it then isn
On 03.04.2020 00:18, Andrew Cooper wrote:
> On 20/12/2019 16:01, Andrew Cooper wrote:
>>> Suggested-by: Andrew Cooper
>>> Signed-off-by: Jan Beulich
>>> ---
>>> I'll be happy to take suggestions allowing to avoid -Wno-unused-label.
>> I think I'm going to need a little while to figure out how thi
On 03.04.2020 01:12, Andrew Cooper wrote:
> On 24/03/2020 12:34, Jan Beulich wrote:
>> Introduce a new blk() hook, paralleling the rmw() on in certain way, but
>> being intended for larger data sizes, and hence its HVM intermediate
>> handling function doesn't fall back to splitting the operation i
On 03.04.2020 01:47, Andrew Cooper wrote:
> On 24/03/2020 12:37, Jan Beulich wrote:
>> The dependency on a new EFER bit implies that we need to set that bit
>> ourselves in order to be able to successfully invoke the insn.
>>
>> Also once again introduce the SVM related constants at this occasion.
On 02.04.2020 16:58, Andrew Cooper wrote:
> On 02/04/2020 09:22, Jan Beulich wrote:
>> As requested in reply to v1, this is now a pair of patches with
>> the expectation that only patch 1 would be acked and go in.
>>
>> 1: drop Cannon Lake support
>> 2: support Cannon Lake (again)
>
> Dropping Can
On 02.04.2020 21:27, Andrew Cooper wrote:
> On 20/12/2019 14:06, Jan Beulich wrote:
>> While the mere updating of ->pv_cr3 and ->root_pgt_changed aren't overly
>> expensive (but still needed only for the toggle_guest_mode() path), the
>> effect of the latter on the exit-to-guest path is not insigni
On 03.04.2020 00:43, Andrew Cooper wrote:
> On 01/04/2020 12:39, Jan Beulich wrote:
>> @@ -790,21 +789,23 @@ p2m_remove_page(struct p2m_domain *p2m,
>>&cur_order, NULL);
>>
>> if ( p2m_is_valid(t) &&
>> - (!mfn_valid(_mfn(mfn)) || m
On 02.04.2020 16:00, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 02 April 2020 12:08
>>
>> Considering the situation with event channels (all closed), doing
>> what you do for the shared info page is probably going to be fine;
>> large parts of it are in a known
On 2020-04-02 19:52, Julien Grall wrote:
(+Marc)
Thanks for looping me in. Definitely an interesting read, but also a
very
puzzling one.
Hi Stefano,
On 02/04/2020 18:19, Stefano Stabellini wrote:
On Wed, 1 Apr 2020, Julien Grall wrote:
On 01/04/2020 01:57, Stefano Stabellini wrote:
On
Commit 1d5c76e664333 ("xen-blkfront: switch kcalloc to kvcalloc for
large array allocation") didn't fix the issue it was meant to, as the
flags for allocating the memory are GFP_NOIO, which will lead the
memory allocation falling back to kmalloc().
So instead of GFP_NOIO use GFP_KERNEL and do all
Hi,
On 03/04/2020 06:27, osstest service owner wrote:
flight 149335 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149335/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 18 gue
On 03.04.2020 11:08, Julien Grall wrote:
> Hi,
>
> On 03/04/2020 06:27, osstest service owner wrote:
>> flight 149335 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/149335/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests wh
On 03/04/2020 10:11, Jan Beulich wrote:
On 03.04.2020 11:08, Julien Grall wrote:
Hi,
On 03/04/2020 06:27, osstest service owner wrote:
flight 149335 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149335/
Regressions :-(
Tests which did not succeed and are blocki
On 03.04.2020 00:43, Andrew Cooper wrote:
> On 01/04/2020 12:39, Jan Beulich wrote:
>> @@ -790,21 +789,23 @@ p2m_remove_page(struct p2m_domain *p2m,
>>&cur_order, NULL);
>>
>> if ( p2m_is_valid(t) &&
>> - (!mfn_valid(_mfn(mfn)) || m
flight 149344 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149344/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs.
144861
test-amd6
> On Apr 3, 2020, at 9:47 AM, Marc Zyngier wrote:
>
> On 2020-04-02 19:52, Julien Grall wrote:
>> (+Marc)
>
> Thanks for looping me in. Definitely an interesting read, but also a very
> puzzling one.
[snip]
> No. Low latency is a very desirable thing, but it doesn't matter at all when
> you
George,
On 2020-04-03 11:43, George Dunlap wrote:
On Apr 3, 2020, at 9:47 AM, Marc Zyngier wrote:
On 2020-04-02 19:52, Julien Grall wrote:
(+Marc)
Thanks for looping me in. Definitely an interesting read, but also a
very
puzzling one.
[snip]
No. Low latency is a very desirable thing, b
> On Apr 3, 2020, at 11:59 AM, Marc Zyngier wrote:
>
> George,
>
> On 2020-04-03 11:43, George Dunlap wrote:
>>> On Apr 3, 2020, at 9:47 AM, Marc Zyngier wrote:
>>> On 2020-04-02 19:52, Julien Grall wrote:
(+Marc)
>>> Thanks for looping me in. Definitely an interesting read, but also a v
On 03/04/2020 11:43, George Dunlap wrote:
On Apr 3, 2020, at 9:47 AM, Marc Zyngier wrote:
On 2020-04-02 19:52, Julien Grall wrote:
(+Marc)
Thanks for looping me in. Definitely an interesting read, but also a very
puzzling one.
[snip]
No. Low latency is a very desirable thing, but it
flight 149348 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149348/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 149238
Regressions which a
Commit 562a1c0f7ef3fb ("tools/xenstore: dont unlink connection object
twice") introduced a potential use after free problem in
domain_cleanup(): after calling talloc_unlink() for domain->conn
domain->conn is set to NULL. The problem is that domain is registered
as talloc child of domain->conn, so i
flight 149382 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149382/
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
Hi all,
I am trying to understand how live-migration happens in xen. I am
looking in the HVM guest case and I have dug into the relevant parts
of the toolstack and the hypervisor regarding memory, vCPU context
etc.
In particular, I am interested in how PV device migration happens. I
assume that t
On 03/04/2020 13:32, Anastassios Nanos wrote:
> Hi all,
>
> I am trying to understand how live-migration happens in xen. I am
> looking in the HVM guest case and I have dug into the relevant parts
> of the toolstack and the hypervisor regarding memory, vCPU context
> etc.
>
> In particular, I am in
This fixes the fact that qemu-deprivilege.md, non-cooperative-migration.md and
xenstore-migration.md don't currently get rendered at all, and are therefore
missing from xenbits.xen.org/docs
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Paul Durrant
CC: Ian Jackson
Ian - given qemu-de
On 02.04.2020 12:18, Andrew Cooper wrote:
> The CPUID instruction is expensive. No point executing it twice when once
> will do fine.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
albeit ...
> --- a/xen/arch/x86/cpu/microcode/intel.c
> +++ b/xen/arch/x86/cpu/microcode/intel.c
> @@
On 02.04.2020 12:18, Andrew Cooper wrote:
> It turns out there are no callers of the hook(). The only callers are the
> local, which can easily be rearranged to use the appropriate internal helper.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 02.04.2020 12:19, Andrew Cooper wrote:
> No paths to apply_microcode() pass a NULL pointer, and other hooks don't
> tolerate one in the first place. We can expect the core logic not to pass us
> junk, so drop the checks.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 02.04.2020 12:19, Andrew Cooper wrote:
> With the newly cleaned up vendor logic, each struct microcode_patch is a
> trivial object in memory with no dependent allocations.
>
> This is unlikely to change moving forwards, and function pointers are
> expensive in the days of retpoline. Move the r
On 02.04.2020 12:19, Andrew Cooper wrote:
> All callers pass &this_cpu(cpu_sig) for the cpu_sig parameter, and all
> implementations unconditionally return 0. Simplify it to be void.
>
> Drop the long-stale comment on the AMD side, whose counterpart in
> start_update() used to be "collect_cpu_inf
> -Original Message-
> From: Xen-devel On Behalf Of Andrew
> Cooper
> Sent: 03 April 2020 14:17
> To: Xen-devel
> Cc: George Dunlap ; Andrew Cooper
> ; Paul
> Durrant ; Ian Jackson
> Subject: [PATCH] docs: Render .md files using pandoc
>
> This fixes the fact that qemu-deprivilege.md,
On 02.04.2020 18:18, Igor Druzhinin wrote:
> The area just below 4G where OVMF image is originally relocated is not
> necessarily a hole - it might contain pages preallocated by device model
> or the toolstack. By unconditionally populating on top of this memory
> the original pages are getting los
Hi Juergen,
On 03/04/2020 13:03, Juergen Gross wrote:
Commit 562a1c0f7ef3fb ("tools/xenstore: dont unlink connection object
twice") introduced a potential use after free problem in
domain_cleanup(): after calling talloc_unlink() for domain->conn
domain->conn is set to NULL. The problem is that d
On 02.04.2020 17:46, Juergen Gross wrote:
> In case opt_ept_ad has not been set explicitly by the user via command
> line or runtime parameter, it is treated as "no" on Avoton cpus.
>
> Change that handling by setting opt_ept_ad to 0 for this cpu type
> explicitly if no user value has been set.
>
flight 149361 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149361/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
146121
Regressions w
On 02.04.2020 17:46, Juergen Gross wrote:
> Add the infrastructure for the hypervisor filesystem.
>
> This includes the hypercall interface and the base functions for
> entry creation, deletion and modification.
>
> In order not to have to repeat the same pattern multiple times in case
> adding a
On 03/04/2020 14:53, Jan Beulich wrote:
> On 02.04.2020 18:18, Igor Druzhinin wrote:
>> The area just below 4G where OVMF image is originally relocated is not
>> necessarily a hole - it might contain pages preallocated by device model
>> or the toolstack. By unconditionally populating on top of thi
flight 149368 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149368/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f73c9adfc68c7ff189b17cb2531a071d4b30cd75
baseline version:
ovmf 4deef2d865efdc61d1a53
On 02.04.2020 17:46, Juergen Gross wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -353,6 +353,16 @@ config DOM0_MEM
>
> Leave empty if you are not sure what to specify.
>
> +config HYPFS_CONFIG
> + bool "Provide hypervisor .config via hypfs entry"
> + default
On 03.04.2020 16:26, Igor Druzhinin wrote:
> On 03/04/2020 14:53, Jan Beulich wrote:
>> On 02.04.2020 18:18, Igor Druzhinin wrote:
>>> The area just below 4G where OVMF image is originally relocated is not
>>> necessarily a hole - it might contain pages preallocated by device model
>>> or the tools
On 03/04/2020 14:53, Jan Beulich wrote:
> On 02.04.2020 18:18, Igor Druzhinin wrote:
>> The area just below 4G where OVMF image is originally relocated is not
>> necessarily a hole - it might contain pages preallocated by device model
>> or the toolstack. By unconditionally populating on top of thi
On 03/04/2020 10:14, Jan Beulich wrote:
> On 03.04.2020 00:43, Andrew Cooper wrote:
>> On 01/04/2020 12:39, Jan Beulich wrote:
>>> @@ -790,21 +789,23 @@ p2m_remove_page(struct p2m_domain *p2m,
>>>&cur_order, NULL);
>>>
>>> if ( p2m_is_valid(t)
On 03/04/2020 15:39, Andrew Cooper wrote:
> On 03/04/2020 14:53, Jan Beulich wrote:
>> On 02.04.2020 18:18, Igor Druzhinin wrote:
>>> The area just below 4G where OVMF image is originally relocated is not
>>> necessarily a hole - it might contain pages preallocated by device model
>>> or the toolst
On 02.04.2020 17:46, Juergen Gross wrote:
> V7:
> - fine tune some parameter initializations (Jan Beulich)
> - call custom_runtime_set_var() after updating the value
> - modify alignment in Arm linker script to 4 (Jan Beulich)
I didn't ask for this to be unilaterally 4 - I don't think this
would w
On 03.04.20 16:05, Jan Beulich wrote:
On 02.04.2020 17:46, Juergen Gross wrote:
In case opt_ept_ad has not been set explicitly by the user via command
line or runtime parameter, it is treated as "no" on Avoton cpus.
Change that handling by setting opt_ept_ad to 0 for this cpu type
explicitly if
On 03/04/2020 09:00, Jan Beulich wrote:
> On 03.04.2020 01:47, Andrew Cooper wrote:
>> On 24/03/2020 12:37, Jan Beulich wrote:
>>> The dependency on a new EFER bit implies that we need to set that bit
>>> ourselves in order to be able to successfully invoke the insn.
>>>
>>> Also once again introdu
On 03.04.2020 16:47, Igor Druzhinin wrote:
> On 03/04/2020 15:39, Andrew Cooper wrote:
>> On 03/04/2020 14:53, Jan Beulich wrote:
>>> On 02.04.2020 18:18, Igor Druzhinin wrote:
The area just below 4G where OVMF image is originally relocated is not
necessarily a hole - it might contain pag
On 03.04.20 16:23, Jan Beulich wrote:
On 02.04.2020 17:46, Juergen Gross wrote:
Add the infrastructure for the hypervisor filesystem.
This includes the hypercall interface and the base functions for
entry creation, deletion and modification.
In order not to have to repeat the same pattern mult
On 03/04/2020 09:06, Jan Beulich wrote:
> On 02.04.2020 16:58, Andrew Cooper wrote:
>> On 02/04/2020 09:22, Jan Beulich wrote:
>>> As requested in reply to v1, this is now a pair of patches with
>>> the expectation that only patch 1 would be acked and go in.
>>>
>>> 1: drop Cannon Lake support
>>>
On 03.04.2020 17:00, Andrew Cooper wrote:
> On 03/04/2020 09:00, Jan Beulich wrote:
>> On 03.04.2020 01:47, Andrew Cooper wrote:
>>> On 24/03/2020 12:37, Jan Beulich wrote:
The dependency on a new EFER bit implies that we need to set that bit
ourselves in order to be able to successfully
On 03.04.20 16:31, Jan Beulich wrote:
On 02.04.2020 17:46, Juergen Gross wrote:
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -353,6 +353,16 @@ config DOM0_MEM
Leave empty if you are not sure what to specify.
+config HYPFS_CONFIG
+ bool "Provide hypervisor .config via hy
On 03/04/2020 08:57, Jan Beulich wrote:
> On 03.04.2020 01:12, Andrew Cooper wrote:
>> On 24/03/2020 12:34, Jan Beulich wrote:
>>> Introduce a new blk() hook, paralleling the rmw() on in certain way, but
>>> being intended for larger data sizes, and hence its HVM intermediate
>>> handling function
On 03/04/2020 16:05, Jan Beulich wrote:
> On 03.04.2020 16:47, Igor Druzhinin wrote:
>> On 03/04/2020 15:39, Andrew Cooper wrote:
>>> On 03/04/2020 14:53, Jan Beulich wrote:
On 02.04.2020 18:18, Igor Druzhinin wrote:
> The area just below 4G where OVMF image is originally relocated is not
> -Original Message-
> From: Jan Beulich
> Sent: 30 March 2020 11:54
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Ian Jackson ;
> Wei Liu
> Subject: Re: [PATCH 3/5] tools/misc: add xen-ctx to present domain context
>
> On 27.03.2020 19:50, Paul Durrant wrote:
> > This tools
flight 149376 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149376/
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
On 03.04.2020 17:13, Andrew Cooper wrote:
> On 03/04/2020 08:57, Jan Beulich wrote:
>> On 03.04.2020 01:12, Andrew Cooper wrote:
>>> On 24/03/2020 12:34, Jan Beulich wrote:
Introduce a new blk() hook, paralleling the rmw() on in certain way, but
being intended for larger data sizes, and h
On 03/04/2020 16:09, Jan Beulich wrote:
> On 03.04.2020 17:00, Andrew Cooper wrote:
>> On 03/04/2020 09:00, Jan Beulich wrote:
>>> On 03.04.2020 01:47, Andrew Cooper wrote:
On 24/03/2020 12:37, Jan Beulich wrote:
> The dependency on a new EFER bit implies that we need to set that bit
>
On 03.04.2020 17:17, Igor Druzhinin wrote:
> On 03/04/2020 16:05, Jan Beulich wrote:
>> On 03.04.2020 16:47, Igor Druzhinin wrote:
>>> There multiple technical complications that caused this mess.
>>> One of them is that there is no unfortunately a better place for the
>>> framebuffer to be located
On 03.04.2020 17:20, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 30 March 2020 11:54
>> To: Paul Durrant
>> Cc: xen-devel@lists.xenproject.org; Ian Jackson ;
>> Wei Liu
>> Subject: Re: [PATCH 3/5] tools/misc: add xen-ctx to present domain context
>>
>> On 27.
On 03.04.20 16:51, Jan Beulich wrote:
On 02.04.2020 17:46, Juergen Gross wrote:
V7:
- fine tune some parameter initializations (Jan Beulich)
- call custom_runtime_set_var() after updating the value
- modify alignment in Arm linker script to 4 (Jan Beulich)
I didn't ask for this to be unilatera
On 03.04.2020 17:05, Jürgen Groß wrote:
> On 03.04.20 16:23, Jan Beulich wrote:
>> On 02.04.2020 17:46, Juergen Gross wrote:
>>> +int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
>>> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long
>>> ulen)
>>> +{
>>> + char *buf;
>>>
On 03.04.20 17:31, Jan Beulich wrote:
On 03.04.2020 17:05, Jürgen Groß wrote:
On 03.04.20 16:23, Jan Beulich wrote:
On 02.04.2020 17:46, Juergen Gross wrote:
+int hypfs_write_leaf(struct hypfs_entry_leaf *leaf,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+{
+
On 03.04.2020 17:12, Jürgen Groß wrote:
> On 03.04.20 16:31, Jan Beulich wrote:
>> On 02.04.2020 17:46, Juergen Gross wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -353,6 +353,16 @@ config DOM0_MEM
>>> Leave empty if you are not sure what to specify.
>>> +confi
On 03/04/2020 16:28, Jan Beulich wrote:
> On 03.04.2020 17:17, Igor Druzhinin wrote:
>> On 03/04/2020 16:05, Jan Beulich wrote:
>>> On 03.04.2020 16:47, Igor Druzhinin wrote:
There multiple technical complications that caused this mess.
One of them is that there is no unfortunately a bett
On 03.04.20 17:33, Jan Beulich wrote:
On 03.04.2020 17:12, Jürgen Groß wrote:
On 03.04.20 16:31, Jan Beulich wrote:
On 02.04.2020 17:46, Juergen Gross wrote:
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -353,6 +353,16 @@ config DOM0_MEM
Leave empty if you are not sure what t
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.7-rc1-tag
xen: branch for v5.7-rc1
It contains:
- a cleanup patch removing an unused function
- a small fix for the xen pciback driver
- a series for making the unwinder hyppay with
> -Original Message-
[snip]
> > +
> > +#include
> > +
> > +struct domain_context {
> > +bool log;
> > +struct domain_save_descriptor desc;
> > +domain_copy_entry copy;
>
> As your new framework is technically an extension of existing one, it
> would be good to explain why we d
> -Original Message-
> From: Jan Beulich
> Sent: 03 April 2020 16:30
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; 'Ian Jackson'
> ; 'Wei Liu'
> Subject: Re: [PATCH 3/5] tools/misc: add xen-ctx to present domain context
>
> On 03.04.2020 17:20, Paul Durrant wrote:
> >> -O
> -Original Message-
> From: Xen-devel On Behalf Of Igor
> Druzhinin
> Sent: 03 April 2020 16:36
> To: Jan Beulich
> Cc: Andrew Cooper ; roger@citrix.com;
> ian.jack...@eu.citrix.com;
> w...@xen.org; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH] hvmloader: probe memory below
On Fri, 3 Apr 2020, Marc Zyngier wrote:
> > > Yeah I missed to highlight it, also because I look at it from a slightly
> > > different perspective: I think IRQ latency is part of correctness.
>
> No. Low latency is a very desirable thing, but it doesn't matter at all when
> you don't even have fun
On 03/04/2020 17:18, Stefano Stabellini wrote:
On Fri, 3 Apr 2020, Marc Zyngier wrote:
> Doing what my patch here does might be OK until one of these guests
start to rely on ISACTIVER to be accurate. So far I have not seen any
examples of it, but I agree it could happen, hence, it is risky.
Andrew Cooper writes ("[PATCH] docs: Render .md files using pandoc"):
> This fixes the fact that qemu-deprivilege.md, non-cooperative-migration.md and
> xenstore-migration.md don't currently get rendered at all, and are therefore
> missing from xenbits.xen.org/docs
>
> Signed-off-by: Andrew Cooper
Julien Grall writes ("Re: [PATCH v2] tools/xenstore: fix a use after free
problem in xenstored"):
> On 03/04/2020 13:03, Juergen Gross wrote:
> > Commit 562a1c0f7ef3fb ("tools/xenstore: dont unlink connection object
> > twice") introduced a potential use after free problem in
> > domain_cleanup():
Hi Paul,
On 03/04/2020 16:55, Paul Durrant wrote:
-Original Message-
[snip]
+
+#include
+
+struct domain_context {
+bool log;
+struct domain_save_descriptor desc;
+domain_copy_entry copy;
As your new framework is technically an extension of existing one, it
would be good
On 03/04/2020 17:23, Julien Grall wrote:
On 03/04/2020 17:18, Stefano Stabellini wrote:
On Fri, 3 Apr 2020, Marc Zyngier wrote:
> Doing what my patch here does might be OK until one of these guests
start to rely on ISACTIVER to be accurate. So far I have not seen any
examples of it, but
flight 149391 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149391/
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
On Thu, 2 Apr 2020, Julien Grall wrote:
> As we discussed on Tuesday, the cost for other vCPUs is only going to be a
> trap to the hypervisor and then back again. The cost is likely smaller than
> receiving and forwarding an interrupt.
>
> You actually agreed on this analysis. So can you enlighten
On Fri, 3 Apr 2020 at 20:41, Stefano Stabellini wrote:
>
> On Thu, 2 Apr 2020, Julien Grall wrote:
> > As we discussed on Tuesday, the cost for other vCPUs is only going to be a
> > trap to the hypervisor and then back again. The cost is likely smaller than
> > receiving and forwarding an interrup
The pull request you sent on Fri, 3 Apr 2020 17:54:57 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.7-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6cd3d4019ba3f45aa1a87e4e914e81d367b59937
Thank you!
--
Deet-doot-dot, I
On 4/3/20 5:00 AM, Juergen Gross wrote:
> Commit 1d5c76e664333 ("xen-blkfront: switch kcalloc to kvcalloc for
> large array allocation") didn't fix the issue it was meant to, as the
> flags for allocating the memory are GFP_NOIO, which will lead the
> memory allocation falling back to kmalloc().
Hi Andrew,
On 4/3/20 5:42 AM, Andrew Cooper wrote:
> On 03/04/2020 13:32, Anastassios Nanos wrote:
>> Hi all,
>>
>> I am trying to understand how live-migration happens in xen. I am
>> looking in the HVM guest case and I have dug into the relevant parts
>> of the toolstack and the hypervisor regar
flight 149401 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149401/
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 149378 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149378/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 149188
Tests which did not succeed
flight 149383 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149383/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs.
144861
test-amd6
85 matches
Mail list logo
