flight 145542 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145542/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 145511
build-arm64-libvirt
flight 145523 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145523/
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.
145025
Tests
Hi,
I have a multi-function PCI device, behind a PCI bridge, that normally
I assign to a single domain. But now it fails with:
(XEN) [VT-D]d14: :04:00.0 owned by d0!<0>assign :05:00.0 to dom14
failed (-22)
This is Xen 4.8.5 + XSA patches. It started happening after some update
during
flight 145531 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145531/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 145518 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145518/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 14 guest-saverestore fail REGR. vs. 144861
XCFLAGS_CHECKPOINT_COMPRESS has been unused since c/s b15bc4345 (2015),
XCFLAGS_HVM since c/s 9e8672f1c (2013), and XCFLAGS_STDVGA since c/s
087d43326 (2007). Drop the constants, and code which sets them.
The separate hvm parameter (appeared in c/s d11bec8a1, 2007 and ultimately
redundant with
The net diffstat is:
add/remove: 0/13 grow/shrink: 25/129 up/down: 6297/-20469 (-14172)
With the following objects/functions removed entirely:
iommu_hwdom_none 1 - -1
hwdom_max_order4 - -4
extra_hwdom_irqs
flight 145526 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145526/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Tue, Dec 24, 2019 at 8:06 AM Paul Durrant wrote:
>
> This patch modifies do_domain_create() to use the value of domid that is
> passed in. A new 'special value' - RANDOM_DOMID - is added into the API
> and this, INVALID_DOMID or any valid domid is passed unmodified to
> libxl__domain_make().
On 03/01/2020 14:34, Jan Beulich wrote:
> On 03.01.2020 15:25, Andrew Cooper wrote:
>> On 03/01/2020 13:52, Jan Beulich wrote:
>>> On 03.01.2020 14:44, Andrew Cooper wrote:
On 03/01/2020 13:36, Jan Beulich wrote:
> On 02.01.2020 15:59, Andrew Cooper wrote:
>> @@ -111,26 +109,6 @@
On Fri, Jan 3, 2020 at 3:10 AM Jan Beulich wrote:
>
> On 31.12.2019 23:17, Roman Shaposhnik wrote:
> > here's a silly question: whenever Xen is provided with a VGA console,
> > where's the keyboard driver coming from? Quick to my surprise, my
> > casual inspection of the drivers/ folder didn't
On Fri, Jan 03, 2020 at 06:29:35PM +0100, Roger Pau Monne wrote:
> There are issues (as reported by osstest [0]) when Xen is running
> nested on itself and the L1 Xen is using x2APIC. While those are being
> investigated, disable announcing the x2APIC feature in CPUID when
> nested HVM mode is
On 03/01/2020 17:29, Roger Pau Monne wrote:
> There are issues (as reported by osstest [0]) when Xen is running
> nested on itself and the L1 Xen is using x2APIC. While those are being
> investigated, disable announcing the x2APIC feature in CPUID when
> nested HVM mode is enabled.
>
> [0]
There are issues (as reported by osstest [0]) when Xen is running
nested on itself and the L1 Xen is using x2APIC. While those are being
investigated, disable announcing the x2APIC feature in CPUID when
nested HVM mode is enabled.
[0] http://logs.test-lab.xenproject.org/osstest/logs/145509/
The hvm and pae parameters are a remnant of legacy migration. They have 0
passed in from libxl_stream_read.c's process_record(), and are discarded in
xc_domain_restore().
While dropping these, update the doxygen comment to be accurate, and simplify
the other hvm vs pv handling in
Hi Andrew,
On 02/01/2020 13:56, Andrew Cooper wrote:
No functional change.
Signed-off-by: Andrew Cooper
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On Fri, Jan 03, 2020 at 04:57:11PM +, Andrew Cooper wrote:
> On 03/01/2020 16:55, Wei Liu wrote:
> > On Fri, Jan 03, 2020 at 04:30:49PM +, Andrew Cooper wrote:
> >> On 03/01/2020 16:08, Wei Liu wrote:
> >>> @@ -83,14 +84,39 @@ static void __init setup_hypercall_page(void)
> >>>
On 03/01/2020 16:55, Wei Liu wrote:
> On Fri, Jan 03, 2020 at 04:30:49PM +, Andrew Cooper wrote:
>> On 03/01/2020 16:08, Wei Liu wrote:
>>> @@ -83,14 +84,39 @@ static void __init setup_hypercall_page(void)
>>> wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
>>> }
>>>
>>> +static
On Fri, Jan 03, 2020 at 04:30:49PM +, Andrew Cooper wrote:
> On 03/01/2020 16:08, Wei Liu wrote:
> > @@ -83,14 +84,39 @@ static void __init setup_hypercall_page(void)
> > wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> > }
> >
> > +static void setup_hypercall_pcpu_arg(void)
>
On 17.12.2019 11:58, Anthony PERARD wrote:
> --- a/xen/Kconfig
> +++ b/xen/Kconfig
> @@ -4,9 +4,26 @@
> #
> mainmenu "Xen/$(SRCARCH) $(XEN_FULLVERSION) Configuration"
>
> +source "scripts/Kconfig.include"
> +
> config BROKEN
> bool
>
> +config CC_IS_GCC
> + def_bool
On 03/01/2020 16:08, Wei Liu wrote:
> @@ -83,14 +84,39 @@ static void __init setup_hypercall_page(void)
> wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> }
>
> +static void setup_hypercall_pcpu_arg(void)
> +{
> +struct page_info *pg;
> +void *mapping;
> +unsigned int
On Fri, Jan 03, 2020 at 05:16:53PM +0100, Jan Beulich wrote:
> On 29.12.2019 19:33, Wei Liu wrote:
> > We will provide a header file for Hyper-V hypercalls.
> >
> > No functional change.
> >
> > Signed-off-by: Wei Liu
>
> In principle
> Acked-by: Jan Beulich
> albeit ...
>
> > ---
> >
On 29.12.2019 19:33, Wei Liu wrote:
> We will provide a header file for Hyper-V hypercalls.
>
> No functional change.
>
> Signed-off-by: Wei Liu
In principle
Acked-by: Jan Beulich
albeit ...
> ---
> xen/include/asm-x86/guest.h| 2 +-
>
On 03.01.2020 12:01, Paul Durrant wrote:
> On Sun, 29 Dec 2019 at 18:34, Wei Liu wrote:
>> --- a/xen/arch/x86/guest/hyperv/hyperv.c
>> +++ b/xen/arch/x86/guest/hyperv/hyperv.c
>> @@ -32,6 +32,8 @@ static const struct hypervisor_ops ops = {
>> const struct hypervisor_ops *__init
On 29.12.2019 19:33, Wei Liu wrote:
> It needs ASSERT_UNREACHABLE.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
This patch sereis implements several important functionalities to run
Xen on top of Hyper-V.
See individual patches for more details.
I can only test them lightly and look at disassembly output to check
correctness at this stage. At the very least Xen on Hyper-V boots up
okay, so it is not
It needs ASSERT_UNREACHABLE.
Signed-off-by: Wei Liu
---
xen/include/asm-x86/guest/pvh-boot.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/include/asm-x86/guest/pvh-boot.h
b/xen/include/asm-x86/guest/pvh-boot.h
index b8a76c4eed..48ffd1a0b1 100644
---
VP assist page is rather important as we need to toggle some bits in
for efficient nested virtualisation.
Preemptively split out set_vp_assist page which will be used in the resume
path.
Signed-off-by: Wei Liu
---
v2:
1. Use HV_HYP_PAGE_SHIFT instead
---
xen/arch/x86/guest/hyperv/hyperv.c | 34
This will be useful when invoking hypercall that targets specific
vcpu(s).
Signed-off-by: Wei Liu
---
v2:
1. Fold into setup_pcpu_arg function
---
xen/arch/x86/guest/hyperv/hyperv.c | 5 +
xen/include/asm-x86/guest/hyperv.h | 1 +
2 files changed, 6 insertions(+)
diff --git
Hyper-V's input / output argument must be 8 bytes aligned an not cross
page boundary. The easiest way to satisfy those requirements is to use
percpu page.
For the foreseeable future we only need to provide input for TLB
and APIC hypercalls, so skip setting up an output page.
The page tracking
We will provide a header file for Hyper-V hypercalls.
No functional change.
Signed-off-by: Wei Liu
Reviewed-by: Paul Durrant
---
xen/include/asm-x86/guest.h| 2 +-
xen/include/asm-x86/guest/{hypercall.h => xen-hypercall.h} | 2 +-
2 files changed, 2
Signed-off-by: Wei Liu
---
v2:
1. Fix issue discovered by Michael
2. Use a statically allocated page as hypercall page
---
xen/arch/x86/guest/hyperv/Makefile | 1 +
xen/arch/x86/guest/hyperv/hypercall_page.S | 21 +
xen/arch/x86/guest/hyperv/hyperv.c | 27
If they are not available, disable Hyper-V related features.
Signed-off-by: Wei Liu
---
v2:
1. Fix comment style
---
xen/arch/x86/guest/hyperv/hyperv.c | 12
1 file changed, 12 insertions(+)
diff --git a/xen/arch/x86/guest/hyperv/hyperv.c
b/xen/arch/x86/guest/hyperv/hyperv.c
These functions will be used later to make hypercalls to Hyper-V.
I couldn't find reference in TLFS that Hyper-V clobbers flags and
r9-r11, but Linux's commit message says it does. Err on the safe side.
Signed-off-by: Wei Liu
---
v2:
1. Use direct call
---
On 23.12.2019 17:43, George Dunlap wrote:
> The comment about the "force-invalidate" loop gives two reasons for
> its existence:
>
> 1. Breaking circular "linear pagetable" references
>
> 2. Cleaning up partially-validated pages.
>
> The first reason been invalid since XSA-240: Since then it
On 23.12.2019 17:43, George Dunlap wrote:
> @@ -1967,42 +1971,32 @@ static int relinquish_memory(
> }
>
> if ( test_and_clear_bit(_PGT_pinned, >u.inuse.type_info) )
> -ret = put_page_and_type_preemptible(page);
> +{
> +/* Always drop the page ref
On 03.01.2020 16:02, Andrew Cooper wrote:
> On 03/01/2020 14:25, Jan Beulich wrote:
>> On 17.12.2019 21:15, Andrew Cooper wrote:
>>> --- a/tools/libxc/include/xc_dom.h
>>> +++ b/tools/libxc/include/xc_dom.h
>>> @@ -123,16 +123,12 @@ struct xc_dom_image {
>>>
>>> /* other state info */
>>>
On 03.01.2020 15:55, Andrew Cooper wrote:
> On 03/01/2020 14:49, Jan Beulich wrote:
>> On 24.12.2019 16:19, Andrew Cooper wrote:
>>> @@ -439,6 +449,34 @@ def verify_record_static_data_end(self, content):
>>> raise RecordError("Static data end record found in v2 stream")
>>>
>>>
flight 145509 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145509/
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.
145025
On 24.12.2019 14:26, Roger Pau Monne wrote:
> @@ -235,6 +236,11 @@ void flush_area_mask(const cpumask_t *mask, const void
> *va, unsigned int flags)
> {
> bool cpus_locked = false;
>
> +if ( xen_guest &&
> + !(flags & ~(FLUSH_TLB | FLUSH_TLB_GLOBAL |
On 24.12.2019 14:26, Roger Pau Monne wrote:
> There's no need to call paging_update_cr3 unless CR3 trapping is
> enabled, and that's only the case when using shadow paging or when
> requested for introspection purposes, otherwise there's no need to
> pause all the vCPUs of the domain in order to
On 03/01/2020 14:25, Jan Beulich wrote:
> On 17.12.2019 21:15, Andrew Cooper wrote:
>> --- a/tools/libxc/include/xc_dom.h
>> +++ b/tools/libxc/include/xc_dom.h
>> @@ -123,16 +123,12 @@ struct xc_dom_image {
>>
>> /* other state info */
>> uint32_t f_active[XENFEAT_NR_SUBMAPS];
>> +
>>
On 03/01/2020 14:49, Jan Beulich wrote:
> On 24.12.2019 16:19, Andrew Cooper wrote:
>> @@ -439,6 +449,34 @@ def verify_record_static_data_end(self, content):
>> raise RecordError("Static data end record found in v2 stream")
>>
>>
>> +def verify_record_x86_cpuid_policy(self,
On 24.12.2019 16:19, Andrew Cooper wrote:
> @@ -439,6 +449,34 @@ def verify_record_static_data_end(self, content):
> raise RecordError("Static data end record found in v2 stream")
>
>
> +def verify_record_x86_cpuid_policy(self, content):
> +""" x86 CPUID policy record
On 24.12.2019 16:19, Andrew Cooper wrote:
> Migration data can be split into two parts - that which is invariant of
> guest execution, and that which is not. Separate these two with the
> STATIC_DATA_END record.
>
> The short term, we want to move the x86 CPU Policy data into the stream.
> In
All,
I am pleased to announce the release of Xen 4.12.2. This is available
immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.12
(tag RELEASE-4.12.2) or from the XenProject download page
On 03.01.2020 15:25, Andrew Cooper wrote:
> On 03/01/2020 13:52, Jan Beulich wrote:
>> On 03.01.2020 14:44, Andrew Cooper wrote:
>>> On 03/01/2020 13:36, Jan Beulich wrote:
On 02.01.2020 15:59, Andrew Cooper wrote:
> @@ -111,26 +109,6 @@ trampoline_protmode_entry:
> start64:
>
On Thu, Dec 19, 2019 at 02:42:17PM +, Anthony PERARD wrote:
> GitLab have a caching capability, see [1]. Let's use it to avoid using
> Internet too often.
>
> The cache is setup so that when xen.git/Config.mk is changed, the
> cache will need to be recreated. This has been chosen because that
On 03/01/2020 13:52, Jan Beulich wrote:
> On 03.01.2020 14:44, Andrew Cooper wrote:
>> On 03/01/2020 13:36, Jan Beulich wrote:
>>> On 02.01.2020 15:59, Andrew Cooper wrote:
@@ -111,26 +109,6 @@ trampoline_protmode_entry:
start64:
/* Jump to high mappings. */
On 17.12.2019 21:15, Andrew Cooper wrote:
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -123,16 +123,12 @@ struct xc_dom_image {
>
> /* other state info */
> uint32_t f_active[XENFEAT_NR_SUBMAPS];
> +
> /*
> - * p2m_host maps guest physical
On Thu, Dec 19, 2019 at 02:42:16PM +, Anthony PERARD wrote:
> This also allows to run `make src-tarball` without first having to run
> `./configure`.
>
> Signed-off-by: Anthony PERARD
Acked-by: Wei Liu
___
Xen-devel mailing list
On Fri, Jan 03, 2020 at 11:11:39AM +, Paul Durrant wrote:
> On Sun, 29 Dec 2019 at 18:35, Wei Liu wrote:
> >
> > This will be useful when invoking hypercall that targets specific
> > vcpu(s).
> >
> > Signed-off-by: Wei Liu
> > ---
> > xen/arch/x86/guest/hyperv/hyperv.c | 12
> >
On 03.01.2020 14:44, Andrew Cooper wrote:
> On 03/01/2020 13:36, Jan Beulich wrote:
>> On 02.01.2020 15:59, Andrew Cooper wrote:
>>> @@ -111,26 +109,6 @@ trampoline_protmode_entry:
>>> start64:
>>> /* Jump to high mappings. */
>>> movabs $__high_start, %rdi
>>> -
>>> -#ifdef
On 03/01/2020 13:36, Jan Beulich wrote:
> On 02.01.2020 15:59, Andrew Cooper wrote:
>> @@ -111,26 +109,6 @@ trampoline_protmode_entry:
>> start64:
>> /* Jump to high mappings. */
>> movabs $__high_start, %rdi
>> -
>> -#ifdef CONFIG_INDIRECT_THUNK
>> -/*
>> - *
On 02.01.2020 15:59, Andrew Cooper wrote:
> @@ -111,26 +109,6 @@ trampoline_protmode_entry:
> start64:
> /* Jump to high mappings. */
> movabs $__high_start, %rdi
> -
> -#ifdef CONFIG_INDIRECT_THUNK
> -/*
> - * If booting virtualised, or hot-onlining a CPU,
On 02.01.2020 17:46, Wei Liu wrote:
> On Thu, Jan 02, 2020 at 01:56:24PM +, Andrew Cooper wrote:
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper
>
> Reviewed-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
On 02.01.2020 17:43, Wei Liu wrote:
> On Thu, 2 Jan 2020 at 16:21, Andrew Cooper wrote:
>>
>> This ought to have disappeared in c/s 60685089cb0
>>
>> Signed-off-by: Andrew Cooper
>
> Reviewed-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel
With libxl suitably adjusted, it is now safe to restore the CPUID/MSR data
directly from the migration stream. Adjust the XGR_SDD_MISSING_* flags for
the static_data_done() callback appropriately.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
---
tools/libxc/xc_sr_common_x86.c
To fix CPUID handling, libxl__build_pre() is going to have to distinguish
between a brand new VM vs one which is being migrated-in/resumed.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Anthony PERARD
The data handling is completely chaotic, but I
This is the incremental work to "Support CPUID/MSR data in migration streams"
which juggles libxl sufficiently to allow us to use the data sent in migration
streams.
The two patches:
tools/libxl: Code-gen improvements for libxl_save_msgs_gen.pl
tools/libxl: Reposition build_pre() logic
The {save,restore}_callback helpers can have their scope reduced vastly, and
helper_setcallbacks_{save,restore}() doesn't need to use a ternary operator to
write 0 (meaning NULL) into an already zeroed structure.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei
CPUID handling needs to be earlier in construction. Move it from its current
position in libxl__build_post() to libxl__build_pre() for fresh builds, and
libxl__srm_callout_callback_static_data_done() for the migration/resume case.
In the migration case, take account of XGR_SDD_MISSING_CPUID.
Further cleanup.
Signed-off-by: Andrew Cooper
---
tools/libxc/include/xenguest.h | 37 -
tools/libxc/xc_sr_save.c | 8
2 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/tools/libxc/include/xenguest.h
libxl is going to have to provide compatibility for pre 4.14 streams which
don't contain CPUID information. Introduce the static_data_done() callback
and plumb it up into libxl.
No overall change.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Anthony PERARD
---
On 03.01.2020 13:34, Roger Pau Monné wrote:
> On Fri, Jan 03, 2020 at 01:08:20PM +0100, Jan Beulich wrote:
>> On 24.12.2019 13:44, Roger Pau Monne wrote:
>> Further a question on lock nesting: Since the commit message
>> doesn't say anything in this regard, did you check there are no
>> TLB flush
On 31.12.2019 08:52, Aaron Janse wrote:
> I'd like to note that Ubuntu, unlike Qubes, doesn't need to try
> any `MP-BIOS bug` fallbacks.
"Doesn't need to try" is supposed to mean what? That it gets past
the timer interrupt initialization, meaning if it crashes another
way, it's a different
On 30.12.2019 00:57, Pry Mar wrote:
> Referencing this report against kernel-5.3 and xen-4.9.2:
> https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1851091
The report there involves seeing a "Decoding failed" message,
which according to commit 2d7572cdfa4d you've successfully
tested to no longer
On Fri, Jan 03, 2020 at 01:08:20PM +0100, Jan Beulich wrote:
> On 24.12.2019 13:44, Roger Pau Monne wrote:
> > @@ -227,14 +233,47 @@ void flush_area_mask(const cpumask_t *mask, const
> > void *va, unsigned int flags)
> > if ( (flags & ~FLUSH_ORDER_MASK) &&
> > !cpumask_subset(mask,
On 03/01/2020 12:08, Jan Beulich wrote:
> On 24.12.2019 13:44, Roger Pau Monne wrote:
>> @@ -227,14 +233,47 @@ void flush_area_mask(const cpumask_t *mask, const void
>> *va, unsigned int flags)
>> if ( (flags & ~FLUSH_ORDER_MASK) &&
>> !cpumask_subset(mask, cpumask_of(cpu)) )
>>
On 23.12.2019 17:43, George Dunlap wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -636,13 +636,29 @@ Available alternatives, with their meaning, are:
> Specify the USB controller to use, either by instance number (when going
> over the PCI busses
On 03.01.2020 12:48, Julien Grall wrote:
> Hi Jan,
>
> Thank you for the information.
>
> On 03/01/2020 11:31, Jan Beulich wrote:
>> On 03.01.2020 12:19, Julien Grall wrote:
>>> How do you manage secondary CPUs on HVM/PVH guest?
>>
>> Secondary CPUs have architectural state they start with, and
On 24.12.2019 13:44, Roger Pau Monne wrote:
> @@ -227,14 +233,47 @@ void flush_area_mask(const cpumask_t *mask, const void
> *va, unsigned int flags)
> if ( (flags & ~FLUSH_ORDER_MASK) &&
> !cpumask_subset(mask, cpumask_of(cpu)) )
> {
> +bool cpus_locked = false;
> +
>
Hi Jan,
Thank you for the information.
On 03/01/2020 11:31, Jan Beulich wrote:
On 03.01.2020 12:19, Julien Grall wrote:
How do you manage secondary CPUs on HVM/PVH guest?
Secondary CPUs have architectural state they start with, and
there's very little control an OS has over initial register
On 03.01.2020 12:19, Julien Grall wrote:
> How do you manage secondary CPUs on HVM/PVH guest?
Secondary CPUs have architectural state they start with, and
there's very little control an OS has over initial register
state: There's just an 8-bit value specifying (part of) the
address the CPU should
Pasi Kärkkäinen writes ("Re: [Xen-devel] [OSSTEST PATCH] Switch to linux-4.19
by default (from 4.14)"):
> On Thu, Jan 02, 2020 at 06:04:33PM +, Ian Jackson wrote:
> > I think given that it's already not perfect this is not a blocker and
> > we should update osstest to 4.14.
> >
flight 145511 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145511/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 145212
test-armhf-armhf-libvirt-raw 13
On 31.12.2019 13:10, Roger Pau Monné wrote:
> On Fri, Dec 27, 2019 at 02:52:17PM +, Andrew Cooper wrote:
>> On 24/12/2019 13:26, Roger Pau Monne wrote:
>>> There's no need to call paging_update_cr3 unless CR3 trapping is
>>> enabled, and that's only the case when using shadow paging or when
Hi,
On 03/01/2020 11:05, Jan Beulich wrote:
On 03.01.2020 11:56, Julien Grall wrote:
Hi,
On 27/12/2019 12:14, Jan Beulich wrote:
On 27.12.2019 12:27, Julien Grall wrote:
Hi Jan,
On Fri, 27 Dec 2019, 09:22 Jan Beulich, wrote:
On 23.12.2019 18:33, Julien Grall wrote:
Hi Jan,
On
On Sun, 29 Dec 2019 at 18:35, Wei Liu wrote:
>
> This will be useful when invoking hypercall that targets specific
> vcpu(s).
>
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/guest/hyperv/hyperv.c | 12
> xen/include/asm-x86/guest/hyperv.h | 1 +
> 2 files changed, 13 insertions(+)
On 31.12.2019 23:17, Roman Shaposhnik wrote:
> here's a silly question: whenever Xen is provided with a VGA console,
> where's the keyboard driver coming from? Quick to my surprise, my
> casual inspection of the drivers/ folder didn't reveal much.
How do "VGA console" and "keyboard driver" match
On Sun, 29 Dec 2019 at 18:35, Wei Liu wrote:
>
> Hyper-V's input / output argument must be 8 bytes aligned an not cross
> page boundary. The easiest way to satisfy those requirements is to use
> percpu page.
>
> For the foreseeable future we only need to provide input for TLB
> and APIC
On 03.01.2020 11:56, Julien Grall wrote:
> Hi,
>
> On 27/12/2019 12:14, Jan Beulich wrote:
>> On 27.12.2019 12:27, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On Fri, 27 Dec 2019, 09:22 Jan Beulich, wrote:
>>>
On 23.12.2019 18:33, Julien Grall wrote:
> Hi Jan,
>
> On 20/12/2019
On Sun, 29 Dec 2019 at 18:34, Wei Liu wrote:
>
> We will provide a header file for Hyper-V hypercalls.
>
> No functional change.
>
> Signed-off-by: Wei Liu
Reviewed-by: Paul Durrant
> ---
> xen/include/asm-x86/guest.h| 2 +-
>
On Sun, 29 Dec 2019 at 18:34, Wei Liu wrote:
>
> If they are not available, disable Hyper-V related features.
>
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/guest/hyperv/hyperv.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/xen/arch/x86/guest/hyperv/hyperv.c
>
Hi,
On 27/12/2019 12:14, Jan Beulich wrote:
On 27.12.2019 12:27, Julien Grall wrote:
Hi Jan,
On Fri, 27 Dec 2019, 09:22 Jan Beulich, wrote:
On 23.12.2019 18:33, Julien Grall wrote:
Hi Jan,
On 20/12/2019 14:55, Jan Beulich wrote:
There's been effectively no use of the field for HVM.
Hi Andrew,
On 02/01/2020 17:40, Andrew Cooper wrote:
On 30/12/2019 13:45, Julien Grall wrote:
Hi,
On 30/12/2019 13:38, Andrew Cooper wrote:
On 30/12/2019 13:15, Julien Grall wrote:
Hi Andrew,
On 27/12/2019 13:45, Andrew Cooper wrote:
The call to xc_domain_disable_migrate() is made only
Hi Andrew,
On 02/01/2020 17:49, Andrew Cooper wrote:
On 23/12/2019 18:23, Julien Grall wrote:
Hi,
On 17/12/2019 21:15, Andrew Cooper wrote:
xc_dom_p2m() and dom->p2m_host[] implement a linear transform for
translated
domains, but waste a substantial chunk of RAM doing so.
ARM literally
On 27.12.2019 16:26, Andrew Cooper wrote:
> On 20/12/2019 13:50, Jan Beulich wrote:
>> It is wrong for us to check the base address when there's no LDT in the
>> first place. Once we don't do this check anymore we can also set the
>> base address to a non-canonical value when the LDT is empty.
>>
On 27.12.2019 16:09, Andrew Cooper wrote:
> On 20/12/2019 13:49, Jan Beulich wrote:
>> It is wrong for us to check frames beyond the guest specified limit
>> (in the native case, other than in the compat one).
>>
>> Signed-off-by: Jan Beulich
>
> Just like the restriction on sharing L2's, no
flight 145502 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145502/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 14 guest-saverestore fail REGR. vs. 144861
On Thu, Jan 02, 2020 at 06:04:33PM +, Ian Jackson wrote:
> This affects only x86 and only the branches that aren't linux-*, since
> obviously the latter use whatever version they are using.
>
> I compared the most recent linux-4.19 results with the most recent
> linux-4.14 ones, and there was
> -Original Message-
> From: Ian Jackson
> Sent: 02 January 2020 17:30
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Wei Liu
> Subject: Re: [PATCH 6/6] xl: allow specified domain id to be used for
> create, restore and migrate
>
> Paul Durrant writes ("[PATCH 6/6] xl: allow
> -Original Message-
> From: Ian Jackson
> Sent: 02 January 2020 17:27
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony Perard
>
> Subject: Re: [PATCH 5/6] libxl: allow creation of domains with specified
> or random domid
>
> Paul Durrant writes ("[PATCH 5/6]
> -Original Message-
> From: Ian Jackson
> Sent: 02 January 2020 17:25
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; George Dunlap ; Jan
> Beulich ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Wei Liu
> Subject: Re: [PATCH 4/6] domctl:
94 matches
Mail list logo
