flight 141084 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141084/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 140844
test-armhf-armhf-xl-a
flight 141083 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141083/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs. 139876
test-amd64-amd64-x
flight 141079 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141079/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129313
build-armhf-pvops
On 06/09/2019 23:30, Boris Ostrovsky wrote:
> On 9/3/19 8:20 PM, Igor Druzhinin wrote:
>> If MCFG area is not reserved in E820, Xen by default will defer its usage
>> until Dom0 registers it explicitly after ACPI parser recognizes it as
>> a reserved resource in DSDT. Having it reserved in E820 i
Hi Konrad,
On 9/5/19 8:13 PM, Konrad Rzeszutek Wilk wrote:
On Tue, Aug 27, 2019 at 08:46:12AM +, Pawel Wieczorkiewicz wrote:
This series introduces new features to the livepatch functionality as
briefly discussed during Xen Developer Summit 2019: [a] and [b].
It also provides a few fixes an
Hi,
Thank you for the new version. However, I nearly missed the v2 as this
is a sub-thread of v1. May I ask you to send a new version as a new
thread instead?
Cheers,
On 8/27/19 9:46 AM, Pawel Wieczorkiewicz wrote:
This series introduces new features to the livepatch functionality as
briefl
On 9/3/19 8:20 PM, Igor Druzhinin wrote:
> If MCFG area is not reserved in E820, Xen by default will defer its usage
> until Dom0 registers it explicitly after ACPI parser recognizes it as
> a reserved resource in DSDT. Having it reserved in E820 is not
> mandatory according to "PCI Firmware Specif
flight 141076 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141076/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win10-i386 broken
test-amd64-i386-xl-qemuu-win10-i386
flight 141086 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141086/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141004
Tests which did
flight 141097 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141097/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 141081 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141081/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 141033
test-armhf-armhf-libvir
On Wed, Sep 4, 2019 at 1:26 PM Daniel Smith wrote:
>
> On Wed, Sep 4, 2019 at 12:12 PM Juergen Gross wrote:
> >
> > The stubdom gets an event channel to use for dom0 xenbstore connection
> > via commandline parameter ("--event "). This needs to be used
> > in the stubdom for setting up the commun
On 06/09/2019 17:00, Arnd Bergmann wrote:
> On Fri, Sep 6, 2019 at 5:55 PM Andrew Cooper
> wrote:
>> On 06/09/2019 16:39, Arnd Bergmann wrote:
>>> HYPERVISOR_platform_op() is an inline function and should not
>>> be exported. Since commit 15bfc2348d54 ("modpost: check for
>>> static EXPORT_SYMBOL
> == Hypervisor ==
>
> * Per-cpu tasklet
> - XEN-28
> - Konrad Rzeszutek Wilk
I haven't gotten to them since the posting three years ago?
I don't think I will get to them anytime soom too :-(
Would love if someone took them over..
P.S:
http://xenbits.xen.org/gitweb/?p=people/konradwilk
flight 141092 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141092/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On 06/09/2019 08:40, Juergen Gross wrote:
> This email only tracks big items for xen.git tree. Please reply for items you
> would like to see in 4.13 so that people have an idea what is going on and
> prioritise accordingly.
>
> You're welcome to provide description and use cases of the feature you
On Fri, Sep 6, 2019 at 5:55 PM Andrew Cooper wrote:
>
> On 06/09/2019 16:39, Arnd Bergmann wrote:
> > HYPERVISOR_platform_op() is an inline function and should not
> > be exported. Since commit 15bfc2348d54 ("modpost: check for
> > static EXPORT_SYMBOL* functions"), this causes a warning:
> >
> >
On 06.09.2019 17:55, Andrew Cooper wrote:
> On 06/09/2019 16:39, Arnd Bergmann wrote:
>> HYPERVISOR_platform_op() is an inline function and should not
>> be exported. Since commit 15bfc2348d54 ("modpost: check for
>> static EXPORT_SYMBOL* functions"), this causes a warning:
>>
>> WARNING: "HYPERVIS
On 06/09/2019 16:39, Arnd Bergmann wrote:
> HYPERVISOR_platform_op() is an inline function and should not
> be exported. Since commit 15bfc2348d54 ("modpost: check for
> static EXPORT_SYMBOL* functions"), this causes a warning:
>
> WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMB
flight 141071 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141071/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 140979 REGR.
vs. 139910
build-amd6
On 06.09.2019 17:27, Andrew Cooper wrote:
> On 06/09/2019 16:18, Jan Beulich wrote:
>> On 05.09.2019 21:49, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -21,45 +21,62 @@ static const uint32_t deep_features[] =
>>> INIT_DEEP_FEATURES;
>>>
>>> static i
On 03.09.2019 16:01, Alexandru Stefan ISAILA wrote:
> A/D bit writes (on page walks) can be considered benign by an introspection
> agent, so receiving vm_events for them is a pessimization. We try here to
> optimize by filtering these events out.
> Currently, we are fully emulating the instruction
HYPERVISOR_platform_op() is an inline function and should not
be exported. Since commit 15bfc2348d54 ("modpost: check for
static EXPORT_SYMBOL* functions"), this causes a warning:
WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
Remove the extraneous export.
Fixes: 15bfc
On 06/09/2019, 16:10, "Roger Pau Monne" wrote:
On Wed, Sep 04, 2019 at 07:12:18PM +0100, Lars Kurth wrote:
[...]
> +## Conduct Team members
> +Conduct Team members are project leadership team members from any
> +sub-project. The current list of Conduct Team members is:
>
On 06/09/2019 16:18, Jan Beulich wrote:
> On 05.09.2019 21:49, Andrew Cooper wrote:
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -21,45 +21,62 @@ static const uint32_t deep_features[] =
>> INIT_DEEP_FEATURES;
>>
>> static int __init parse_xen_cpuid(const char *s)
>> {
>> +
On 05.09.2019 21:49, Andrew Cooper wrote:
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -21,45 +21,62 @@ static const uint32_t deep_features[] =
> INIT_DEEP_FEATURES;
>
> static int __init parse_xen_cpuid(const char *s)
> {
> +static const struct feature {
> +const
On Fri, Sep 06, 2019 at 12:46:03PM +, Lars Kurth wrote:
>
>
> On 06/09/2019, 12:09, "George Dunlap" wrote:
>
> There was a discussion on the community call about the core scheduling
> series being developed by Juergen Gross [1]. The conclusion can be
> summarized as follows:
>
On Wed, Sep 04, 2019 at 07:12:18PM +0100, Lars Kurth wrote:
[...]
> +## Conduct Team members
> +Conduct Team members are project leadership team members from any
> +sub-project. The current list of Conduct Team members is:
> +* Lars Kurth
> +* George Dunlap
> +* Ian Jackson
> +
> +Conduct Team m
On Wed, Sep 04, 2019 at 07:12:16PM +0100, Lars Kurth wrote:
> This series proposes a concrete version of the Xen Project
> CoC based on v1.4 of the Contributor Covenant. See [1]
>
> It also reflects the discussion in [2] and some private
> discussions on IRC to identify initial members of the Xen
On 9/6/19 10:43 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 06, 2019 at 10:19:01AM -0400, Boris Ostrovsky wrote:
>> On 9/6/19 10:01 AM, Christoph Hellwig wrote:
>>> On Fri, Sep 06, 2019 at 09:52:12AM -0400, Boris Ostrovsky wrote:
We need nop definitions of these two for x86.
Every
On Fri, Sep 06, 2019 at 10:19:01AM -0400, Boris Ostrovsky wrote:
> On 9/6/19 10:01 AM, Christoph Hellwig wrote:
> > On Fri, Sep 06, 2019 at 09:52:12AM -0400, Boris Ostrovsky wrote:
> >> We need nop definitions of these two for x86.
> >>
> >> Everything builds now but that's probably because the cal
On 06/09/2019 15:30, Roger Pau Monne wrote:
> Current libxl code will always enable Hardware Assisted Paging (HAP),
> expecting that the hypervisor will fallback to shadow if HAP is not
> available. With the changes to the domain builder that's not the case
"domain builder" is usually libxenguest.
On Fri, Sep 06, 2019 at 04:19:50PM +0200, Jan Beulich wrote:
> On 06.09.2019 16:08, Roger Pau Monné wrote:
> > On Fri, Sep 06, 2019 at 02:08:09PM +0200, Jan Beulich wrote:
> >> On 06.09.2019 13:45, Roger Pau Monné wrote:
> >>> On Fri, Sep 06, 2019 at 12:52:11PM +0200, Jan Beulich wrote:
> On
Current libxl code will always enable Hardware Assisted Paging (HAP),
expecting that the hypervisor will fallback to shadow if HAP is not
available. With the changes to the domain builder that's not the case
any longer, and the hypervisor will raise an error if HAP is not
available instead of silen
Hello,
First patch is a preparatory change to also make use of the physcaps on
ARM, second patch introduces a new physcap (HAP) in order for the
toolstack to decide whether to use HAP if the user hasn't made a
selection.
Thanks, Roger.
Roger Pau Monne (2):
sysctl: report existing physcaps on A
Current physcaps in XEN_SYSCTL_physinfo are only used by x86, albeit
the capabilities themselves are not x86 specific.
This patch adds support for also reporting the current capabilities on
ARM hardware. Note that on ARM PHYSCAP_hvm is always reported, and
setting PHYSCAP_directio has been moved t
On 06.09.2019 16:08, Roger Pau Monné wrote:
> On Fri, Sep 06, 2019 at 02:08:09PM +0200, Jan Beulich wrote:
>> On 06.09.2019 13:45, Roger Pau Monné wrote:
>>> On Fri, Sep 06, 2019 at 12:52:11PM +0200, Jan Beulich wrote:
On 06.09.2019 11:37, Roger Pau Monné wrote:
> On Wed, Jul 03, 2019 a
On 9/6/19 10:01 AM, Christoph Hellwig wrote:
> On Fri, Sep 06, 2019 at 09:52:12AM -0400, Boris Ostrovsky wrote:
>> We need nop definitions of these two for x86.
>>
>> Everything builds now but that's probably because the calls are under
>> 'if (!dev_is_dma_coherent(dev))' which is always false so c
On Fri, Sep 06, 2019 at 03:54:10PM +0200, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel On Behalf Of Paul
> > Durrant
> > Sent: 05 September 2019 14:52
> > To: Roger Pau Monne ; xen-devel@lists.xenproject.org
> > Cc: Stefano Stabellini ; Wei Liu ;
> > Konrad Rzeszutek Wi
On Fri, Sep 06, 2019 at 02:08:09PM +0200, Jan Beulich wrote:
> On 06.09.2019 13:45, Roger Pau Monné wrote:
> > On Fri, Sep 06, 2019 at 12:52:11PM +0200, Jan Beulich wrote:
> >> On 06.09.2019 11:37, Roger Pau Monné wrote:
> >>> On Wed, Jul 03, 2019 at 12:18:45PM +, Jan Beulich wrote:
> --
On 06/09/2019 15:01, Christoph Hellwig wrote:
> On Fri, Sep 06, 2019 at 09:52:12AM -0400, Boris Ostrovsky wrote:
>> We need nop definitions of these two for x86.
>>
>> Everything builds now but that's probably because the calls are under
>> 'if (!dev_is_dma_coherent(dev))' which is always false so
On 06/09/2019 15:01, Jan Beulich wrote:
> Legacy apic init uses bigsmp for smp systems with 8 and more CPUs. The
> bigsmp APIC implementation uses physical destination mode, but it
> nevertheless initializes LDR and DFR. The LDR even ends up incorrectly with
> multiple bit being set.
>
> This does
On 06/09/2019 15:01, Jan Beulich wrote:
> Although APIC initialization will typically clear out the LDR before
> setting it, the APIC cleanup code should reset the LDR.
>
> This was discovered with a 32-bit KVM guest jumping into a kdump
> kernel. The stale bits in the LDR triggered a bug in the KV
Legacy apic init uses bigsmp for smp systems with 8 and more CPUs. The
bigsmp APIC implementation uses physical destination mode, but it
nevertheless initializes LDR and DFR. The LDR even ends up incorrectly with
multiple bit being set.
This does not cause a functional problem because LDR and DFR
On Fri, Sep 06, 2019 at 09:52:12AM -0400, Boris Ostrovsky wrote:
> We need nop definitions of these two for x86.
>
> Everything builds now but that's probably because the calls are under
> 'if (!dev_is_dma_coherent(dev))' which is always false so compiler
> optimized is out. I don't think we shoul
On 06/09/2019 15:00, Jan Beulich wrote:
> There's no point having this if it's not exposed through Kconfig.
>
> Take the liberty and also drop an unnecessary "return" in context.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mai
Although APIC initialization will typically clear out the LDR before
setting it, the APIC cleanup code should reset the LDR.
This was discovered with a 32-bit KVM guest jumping into a kdump
kernel. The stale bits in the LDR triggered a bug in the KVM APIC
implementation which caused the destinatio
There's no point having this if it's not exposed through Kconfig.
Take the liberty and also drop an unnecessary "return" in context.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -189,19 +189,15 @@ void clear_local_APIC(void)
v = apic_read(APIC_LVTPC
The latter two patches are derived from Linux ones, which caught
my attention. The first one is simply some extra code reduction
potential I noticed while evaluating whether those Linux changes
are applicable to our tree.
1: x86: drop CONFIG_X86_MCE_THERMAL
2: x86/apic: include the LDR when cleari
On 06/09/2019 14:54, Jan Beulich wrote:
> From: Zhang Rui
>
> Jacobsville uses the same C-states as Denverton.
>
> Signed-off-by: Zhang Rui
> [Linux commit 04b1d5d098491244f506c4265cc95b87210eef2f]
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
__
> -Original Message-
> From: Xen-devel On Behalf Of Paul
> Durrant
> Sent: 05 September 2019 14:52
> To: Roger Pau Monne ; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Wei Liu ;
> Konrad Rzeszutek Wilk
> ; Andrew Cooper ; Tim
> (Xen.org) ;
> George Dunlap ; Julien Grall
>
From: Zhang Rui
Jacobsville uses the same C-states as Denverton.
Signed-off-by: Zhang Rui
[Linux commit 04b1d5d098491244f506c4265cc95b87210eef2f]
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -962,6 +962,7 @@ static const struct x86_cpu_
On 9/5/19 7:34 AM, Christoph Hellwig wrote:
> diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> index 5e4b83f83dbc..d71380f6ed0b 100644
> --- a/include/xen/swiotlb-xen.h
> +++ b/include/xen/swiotlb-xen.h
> @@ -4,6 +4,11 @@
>
> #include
>
> +void xen_dma_sync_for_cpu(struct
On Fri, Sep 06, 2019 at 03:33:50PM +0200, Jan Beulich wrote:
> On 05.09.2019 18:04, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/xstate.c
> > +++ b/xen/arch/x86/xstate.c
> > @@ -577,7 +577,11 @@ unsigned int xstate_ctxt_size(u64 xcr0)
> > /* Collect the information of processor's extended state *
On Fri, Sep 6, 2019 at 7:02 PM Boris Ostrovsky
wrote:
>
> On 9/6/19 8:27 AM, Souptick Joarder wrote:
> > On Mon, Sep 2, 2019 at 2:04 PM Souptick Joarder
> > wrote:
> >> Rather than using static int max_dma_bits, this
> >> can be coverted to use as macro.
> >>
> >> Signed-off-by: Souptick Joarder
On 05.09.2019 18:04, Roger Pau Monne wrote:
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -577,7 +577,11 @@ unsigned int xstate_ctxt_size(u64 xcr0)
> /* Collect the information of processor's extended state */
> void xstate_init(struct cpuinfo_x86 *c)
> {
> -static bool __
On 9/6/19 8:27 AM, Souptick Joarder wrote:
> On Mon, Sep 2, 2019 at 2:04 PM Souptick Joarder wrote:
>> Rather than using static int max_dma_bits, this
>> can be coverted to use as macro.
>>
>> Signed-off-by: Souptick Joarder
>> Reviewed-by: Juergen Gross
> If it is still not late, can we get thi
On 05.09.2019 21:04, Andrew Cooper wrote:
> All 64-bit capable processors use PAT, and with PAT, it is explicitly
> permitted to have mappings with a cacheability different to MTRRs.
>
> On a native system with a real legacy VGA region, MTRRs will cause the region
> to be UC-.
Minor correction: M
flight 141080 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141080/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 141054
Tests which did not succee
On 06/09/2019 14:12, Jan Beulich wrote:
> On 06.09.2019 14:28, Andrew Cooper wrote:
>> On 06/09/2019 08:29, Jan Beulich wrote:
>>> On 06.09.2019 00:04, osstest service owner wrote:
flight 141063 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141063/
>
Prohibit probing on instruction which has XEN_EMULATE_PREFIX
or KVM's emulate prefix. Since that prefix is a marker for Xen
and KVM, if we modify the marker by kprobe's int3, that doesn't
work as expected.
Signed-off-by: Masami Hiramatsu
---
arch/x86/kernel/kprobes/core.c |4
1 file cha
Decode Xen and KVM's emulate-prefix signature by x86 insn decoder.
It is called "prefix" but actually not x86 instruction prefix, so
this adds insn.emulate_prefix_size field instead of reusing
insn.prefixes.
If x86 decoder finds a special sequence of instructions of
XEN_EMULATE_PREFIX and 'ud2a; .
Gather the emulate prefixes, which forcibly make the following
instruction emulated on virtualization, in one place.
Suggested-by: Peter Zijlstra
Signed-off-by: Masami Hiramatsu
---
arch/x86/include/asm/emulate_prefix.h | 14 ++
arch/x86/include/asm/xen/interface.h | 11 ---
Use __stringify() at __ASM_FORM() so that user can pass
code including macros to __ASM_FORM().
Signed-off-by: Masami Hiramatsu
---
arch/x86/include/asm/asm.h |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h
ind
Hi,
Here is the 4th version of patches to handle Xen/KVM emulate
prefix by x86 instruction decoder.
These patches allow x86 instruction decoder to decode
Xen and KVM emulate prefix correctly, and prohibit kprobes to
probe on it.
Previous version is here;
https://lkml.kernel.org/r/156773433821.3
On 06.09.2019 14:28, Andrew Cooper wrote:
> On 06/09/2019 08:29, Jan Beulich wrote:
>> On 06.09.2019 00:04, osstest service owner wrote:
>>> flight 141063 xen-unstable-smoke real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/141063/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not
On 06/09/2019, 12:09, "George Dunlap" wrote:
There was a discussion on the community call about the core scheduling
series being developed by Juergen Gross [1]. The conclusion can be
summarized as follows:
* We normally wait to check in series until they are quite good --
The Makefile below tools/libs have a lot in common. Put those common
parts into a new libs.mk and include that from the specific Makefiles.
Signed-off-by: Juergen Gross
---
V2:
- include common Makefile via absolute path for not breaking stubdom
---
tools/libs/call/Makefile | 86 ++-
flight 141062 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141062/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 140955 REGR.
vs. 139698
Tests which
On Mon, Sep 2, 2019 at 2:04 PM Souptick Joarder wrote:
>
> Rather than using static int max_dma_bits, this
> can be coverted to use as macro.
>
> Signed-off-by: Souptick Joarder
> Reviewed-by: Juergen Gross
If it is still not late, can we get this patch in queue for 5.4 ?
> ---
> drivers/xen/
On 06/09/2019 08:29, Jan Beulich wrote:
> On 06.09.2019 00:04, osstest service owner wrote:
>> flight 141063 xen-unstable-smoke real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/141063/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which
On 06/09/2019 12:09, George Dunlap wrote:
> There was a discussion on the community call about the core scheduling
> series being developed by Juergen Gross [1]. The conclusion can be
> summarized as follows:
>
> * We normally wait to check in series until they are quite good -- all
> the i's dott
On 05/09/2019 09:34, Jan Beulich wrote:
> This is to make the function live up to the promise its name makes. And
> it simplifies all callers.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
I haven't looked at the calculations in detail, but from an end co
On 06.09.2019 13:45, Roger Pau Monné wrote:
> On Fri, Sep 06, 2019 at 12:52:11PM +0200, Jan Beulich wrote:
>> On 06.09.2019 11:37, Roger Pau Monné wrote:
>>> On Wed, Jul 03, 2019 at 12:18:45PM +, Jan Beulich wrote:
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -829
On Fri, Sep 06, 2019 at 12:52:11PM +0200, Jan Beulich wrote:
> On 06.09.2019 11:37, Roger Pau Monné wrote:
> > On Wed, Jul 03, 2019 at 12:18:45PM +, Jan Beulich wrote:
> >> --- a/xen/arch/x86/mm/p2m.c
> >> +++ b/xen/arch/x86/mm/p2m.c
> >> @@ -829,13 +829,13 @@ guest_physmap_add_page(struct dom
On 06/09/2019 12:06, Roger Pau Monné wrote:
> On Thu, Sep 05, 2019 at 08:04:18PM +0100, Andrew Cooper wrote:
>> All 64-bit capable processors use PAT, and with PAT, it is explicitly
>> permitted to have mappings with a cacheability different to MTRRs.
>>
>> On a native system with a real legacy VGA
On Thu, Sep 05, 2019 at 10:34:47AM +0200, Jan Beulich wrote:
> This is to make the function live up to the promise its name makes. And
> it simplifies all callers.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks.
__
There was a discussion on the community call about the core scheduling
series being developed by Juergen Gross [1]. The conclusion can be
summarized as follows:
* We normally wait to check in series until they are quite good -- all
the i's dotted and all the t's crossed
* This is for several rea
On Thu, Sep 05, 2019 at 08:04:18PM +0100, Andrew Cooper wrote:
> All 64-bit capable processors use PAT, and with PAT, it is explicitly
> permitted to have mappings with a cacheability different to MTRRs.
>
> On a native system with a real legacy VGA region, MTRRs will cause the region
> to be UC-.
> -Original Message-
[snip]
> > diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
> > index 35958b94d5..bdf3f2e395 100644
> > --- a/tools/ocaml/libs/xc/xenctrl.ml
> > +++ b/tools/ocaml/libs/xc/xenctrl.ml
> > @@ -56,7 +56,13 @@ type arch_domainconfig =
> > | AR
On 06.09.2019 11:37, Roger Pau Monné wrote:
> On Wed, Jul 03, 2019 at 12:18:45PM +, Jan Beulich wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -829,13 +829,13 @@ guest_physmap_add_page(struct domain *d,
>>*
>>* Retain this property by grabbin
On Fri, 6 Sep 2019 09:34:36 +0200
Peter Zijlstra wrote:
> On Fri, Sep 06, 2019 at 10:45:48AM +0900, Masami Hiramatsu wrote:
>
> > diff --git a/arch/x86/include/asm/xen/interface.h
> > b/arch/x86/include/asm/xen/interface.h
> > index 62ca03ef5c65..fe33a9798708 100644
> > --- a/arch/x86/include/a
On Fri, Sep 06, 2019 at 05:01:09PM +0800, Chao Gao wrote:
> On Thu, Aug 29, 2019 at 12:21:11PM +0200, Roger Pau Monné wrote:
> >On Thu, Aug 29, 2019 at 05:02:27PM +0800, Chao Gao wrote:
> >> Currently, for a HVM on Xen, no reset method is virtualized. So in a VM's
> >> perspective, assigned devices
On Wed, Jul 03, 2019 at 12:18:45PM +, Jan Beulich wrote:
> There are currently three more or less different checks:
> - _get_page_type() adjusts the IOMMU mappings according to the new type
>alone,
> - arch_iommu_populate_page_table() wants just the type to be
>PGT_writable_page,
> - io
flight 141058 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141058/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 12 guest-start fail REGR. vs. 140282
Tests which did n
> -Original Message-
> From: Julien Grall
> Sent: 06 September 2019 10:06
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Ian Jackson ;
> Wei Liu ;
> Andrew Cooper ; George Dunlap
> ; Konrad Rzeszutek
> Wilk ; Stefano Stabellini ;
> Tim (Xen.org)
> ; Anthony Pera
On 06.09.19 11:10, Jan Beulich wrote:
On 06.09.2019 10:49, Juergen Gross wrote:
On 05.09.19 16:43, Jan Beulich wrote:
On 05.09.2019 16:36, Juergen Gross wrote:
On 05.09.19 14:46, Juergen Gross wrote:
On 05.09.19 14:37, Jan Beulich wrote:
On 05.09.2019 14:27, Juergen Gross wrote:
On 05.09.19
> -Original Message-
> From: Chao Gao
> Sent: 06 September 2019 10:01
> To: Roger Pau Monne
> Cc: xen-devel@lists.xenproject.org; qemu-de...@nongnu.org; Stefano Stabellini
> ; Anthony Perard ; Paul
> Durrant
> ; Jan Beulich
> Subject: Re: [RFC Patch] xen/pt: Emulate FLR capability
>
>
On Fri, Sep 06, 2019 at 05:51:43PM +0900, Masami Hiramatsu wrote:
> On Fri, 6 Sep 2019 17:45:19 +0900
> Masami Hiramatsu wrote:
>
> > >
> > > How about we make this asm/virt_prefix.h or something and include:
> > >
> > > /*
> > > * Virt escape sequences to trigger instruction emulation;
> > >
On 06.09.2019 10:49, Juergen Gross wrote:
> On 05.09.19 16:43, Jan Beulich wrote:
>> On 05.09.2019 16:36, Juergen Gross wrote:
>>> On 05.09.19 14:46, Juergen Gross wrote:
On 05.09.19 14:37, Jan Beulich wrote:
> On 05.09.2019 14:27, Juergen Gross wrote:
>> On 05.09.19 14:22, Jan Beulich
Hi Paul,
On 9/6/19 9:08 AM, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 05 September 2019 21:28
To: Paul Durrant ; xen-devel@lists.xenproject.org
Cc: Jan Beulich ; Ian Jackson ; Wei Liu
;
Andrew Cooper ; George Dunlap
; Konrad Rzeszutek
Wilk ; Stefano Stabellini ;
On Thu, Aug 29, 2019 at 12:21:11PM +0200, Roger Pau Monné wrote:
>On Thu, Aug 29, 2019 at 05:02:27PM +0800, Chao Gao wrote:
>> Currently, for a HVM on Xen, no reset method is virtualized. So in a VM's
>> perspective, assigned devices cannot be reset. But some devices rely on PCI
>> reset to recover
On Fri, 6 Sep 2019 17:45:19 +0900
Masami Hiramatsu wrote:
> >
> > How about we make this asm/virt_prefix.h or something and include:
> >
> > /*
> > * Virt escape sequences to trigger instruction emulation;
> > * ideally these would decode to 'whole' instruction and not destroy
> > * the inst
On 05.09.19 16:43, Jan Beulich wrote:
On 05.09.2019 16:36, Juergen Gross wrote:
On 05.09.19 14:46, Juergen Gross wrote:
On 05.09.19 14:37, Jan Beulich wrote:
On 05.09.2019 14:27, Juergen Gross wrote:
On 05.09.19 14:22, Jan Beulich wrote:
On 05.09.2019 14:12, Juergen Gross wrote:
On 05.09.19
Hi Paul,
On 9/6/19 8:59 AM, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 05 September 2019 20:38
To: Paul Durrant ; xen-devel@lists.xenproject.org
Cc: Jan Beulich ; Andrew Cooper ;
George Dunlap
; Ian Jackson ; Konrad
Rzeszutek Wilk
; Stefano Stabellini ; Tim (Xen.o
On Fri, 6 Sep 2019 09:34:36 +0200
Peter Zijlstra wrote:
> On Fri, Sep 06, 2019 at 10:45:48AM +0900, Masami Hiramatsu wrote:
>
> > diff --git a/arch/x86/include/asm/xen/interface.h
> > b/arch/x86/include/asm/xen/interface.h
> > index 62ca03ef5c65..fe33a9798708 100644
> > --- a/arch/x86/include/a
> -Original Message-
> From: Julien Grall
> Sent: 05 September 2019 21:28
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Ian Jackson ;
> Wei Liu ;
> Andrew Cooper ; George Dunlap
> ; Konrad Rzeszutek
> Wilk ; Stefano Stabellini ;
> Tim (Xen.org)
> ; Anthony Pera
> -Original Message-
> From: Julien Grall
> Sent: 05 September 2019 20:59
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Ian Jackson ;
> Wei Liu ;
> Andrew Cooper ; George Dunlap
> ; Konrad Rzeszutek
> Wilk ; Stefano Stabellini ;
> Tim (Xen.org)
> ; Anthony Pera
> -Original Message-
> From: Julien Grall
> Sent: 05 September 2019 20:38
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Konrad
> Rzeszutek Wilk
> ; Stefano Stabellini ; Tim
> (Xen.org) ;
> Wei Liu ; Volodymyr Ba
> -Original Message-
> From: Julien Grall
> Sent: 05 September 2019 21:21
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Alexandru Isaila ; Razvan Cojocaru
> ; Jan
> Beulich ; Stefano Stabellini ;
> Volodymyr Babchuk
> ; Andrew Cooper ;
> George Dunlap
> ; Ian Jackson ; Konra
1 - 100 of 106 matches
Mail list logo
