flight 141053 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141053/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 16 guest-localmigrate fail REGR. vs. 139876
Tests which did no
flight 141054 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141054/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8a1305a11f3bda2d6c1ab758e4aea79ee021dd1c
baseline version:
ovmf adb59b633c12eae334540
flight 141040 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141040/
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. 129313
build-armhf-pvops
flight 141068 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141068/
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
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; .
Hi,
Here is the 3rd 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.
Josh reported that the objtool can not decode such special
prefixed
On Thu, 5 Sep 2019 20:13:50 -0500
Josh Poimboeuf wrote:
> On Fri, Sep 06, 2019 at 09:50:19AM +0900, Masami Hiramatsu wrote:
> > --- a/tools/objtool/sync-check.sh
> > +++ b/tools/objtool/sync-check.sh
> > @@ -4,6 +4,7 @@
> > FILES='
> > arch/x86/include/asm/inat_types.h
> > arch/x86/include/asm
flight 141036 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141036/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 133580
test-amd64-i386-lib
On Fri, Sep 06, 2019 at 09:50:19AM +0900, Masami Hiramatsu wrote:
> --- a/tools/objtool/sync-check.sh
> +++ b/tools/objtool/sync-check.sh
> @@ -4,6 +4,7 @@
> FILES='
> arch/x86/include/asm/inat_types.h
> arch/x86/include/asm/orc_types.h
> +arch/x86/include/asm/xen/prefix.h
> arch/x86/lib/x86-op
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; .
Hi,
Here is the 2nd 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.
Josh reported that the objtool can not decode such special
prefixed
flight 141045 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141045/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 139910
build-amd64
Hi,
We (a group of 2 students) are interested in doing a hypervisor related
project for the next 10-12 weeks as part of one of our courses this
semester. We have taken a look at this year's GSoC project list (
https://wiki.xenproject.org/wiki/Outreach_Program_Projects). We were
interested in learn
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 could not be run:
build-amd64 6 xen-buildfail REGR. vs. 141049
Tests which
Hi,
On 9/2/19 3:50 PM, Paul Durrant wrote:
...and hence the ability to disable IOMMU mappings, and control EPT
sharing.
This patch introduces a new 'libxl_passthrough' enumeration into
libxl_domain_create_info. The value will be set by xl either when it parses
a new 'passthrough' option in xl.c
Hi,
On 9/2/19 3:50 PM, Paul Durrant wrote:
diff --git a/tools/libxl/libxl_mem.c b/tools/libxl/libxl_mem.c
index 448a2af8fd..fd6f33312e 100644
--- a/tools/libxl/libxl_mem.c
+++ b/tools/libxl/libxl_mem.c
@@ -461,15 +461,17 @@ int libxl_domain_need_memory(libxl_ctx *ctx,
if (rc) goto out;
Hi Jan,
On 9/2/19 4:08 PM, Jan Beulich wrote:
On 02.09.2019 16:50, Paul Durrant wrote:
The flag is not needed since the domain 'options' can now be tested
directly.
Signed-off-by: Paul Durrant
In principle
Reviewed-by: Jan Beulich
but
Julien, Stefano,
I'd like to to ask for an explicit o
Hi,
On 9/2/19 3:50 PM, Paul Durrant wrote:
diff --git a/xen/common/domain.c b/xen/common/domain.c
index e9d2c613e0..7dfb257c50 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -301,7 +301,8 @@ static int sanitise_domain_config(struct
xen_domctl_createdomain *config)
Hi,
On 9/2/19 3:50 PM, Paul Durrant wrote:
@@ -263,9 +263,17 @@ struct domain_iommu {
DECLARE_BITMAP(features, IOMMU_FEAT_count);
/*
- * Does the guest reqire mappings to be synchonized, to maintain
- * the default dfn == pfn map. (See comment on dfn at the top of
- *
For gen-cpuid.py, fix a comment describing self.names, and generate the
reverse mapping in self.values. Write out INIT_FEATURE_NAMES which maps a
string name to a bit position.
For parse_cpuid(), use cmdline_strcmp() and perform a binary search over
INIT_FEATURE_NAMES. A tweak to cmdline_strcmp(
Hi Paul,
On 9/2/19 3:50 PM, Paul Durrant wrote:
Thes macros really ought to live in the common xen/iommu.h header rather
then being distributed amongst architecture specific iommu headers and
xen/sched.h. This patch moves them there.
NOTE: Disabling 'sharept' in the command line iommu options s
Hi Paul,
On 9/2/19 3:50 PM, Paul Durrant wrote:
...rather than testing the global iommu_enabled flag and ops pointer.
Now that there is a per-domain flag indicating whether the domain is
permitted to use the IOMMU (which determines whether the ops pointer will
be set), many tests of the global
Hi Paul,
Apologies for the late answer. A couple of comments below.
On 9/2/19 3:50 PM, Paul Durrant wrote:
This patch introduces a common domain creation flag to determine whether
the domain is permitted to make use of the IOMMU. Currently the flag is
always set (for both dom0 and domU) if the
flight 141033 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141033/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 140964
test-armhf-armhf-libvirt-raw 13 saveresto
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 and some small improvements.
>
> Main changes in v2:
> - a
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-. When booting virtualised, this range may be RAM and not a legacy
VGA re
flight 141023 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141023/
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
> diff --git a/docs/misc/livepatch.pandoc b/docs/misc/livepatch.pandoc
> index 6ab7f4c2d2..92a424e918 100644
> --- a/docs/misc/livepatch.pandoc
> +++ b/docs/misc/livepatch.pandoc
> @@ -300,6 +300,7 @@ which describe the functions to be patched:
> /* Added to livepatch payload version 2: */
flight 141049 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141049/
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 Sep 5, 2019, at 12:12, Lars Kurth wrote:
>
> > We can defer the xenstoreless name service topic to the October monthly
> > call.
> >
> > For today's call, can we discuss the previously posted high-level design
> > for unification of the domB RFC with dom0less, as "domB mode" for
> > disag
> We can defer the xenstoreless name service topic to the October monthly call.
>
> For today's call, can we discuss the previously posted high-level design for
> unification of the domB RFC with dom0less, as "domB mode" for
> disaggregation of Xen's dom0?
>
> - domB mode for dom0less (July 2019)
On Thu, 5 Sep 2019 14:31:56 +0100
Andrew Cooper wrote:
> >>> The KVM version was added in c/s 6c86eedc206dd1f9d37a2796faa8e6f2278215d2
> > Hmm, I think I might misunderstand what the "emulate prefix"... that is not
> > a prefix which replace actual prefix, but just works like an escape
> > seque
flight 141015 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141015/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 16 guest-localmigrate fail REGR. vs. 140282
Tests which did n
LLVM code generation can attempt to load from a variable in the next
condition of an expression under certain circumstances, thus
attempting to load use_xsave regardless of the value of the bsp
variable, which leads to a page fault when the init section has
already been unmapped.
Fix this by makin
Don't force the usage of the hardcoded compiler values if those are
already set on the environment. This allows the Xen build system to
correctly pick CC/CXX values present on the environment, and fixes the
usage of those by the Gitlab CI test system.
Note that without this fix the Xen build syste
Include config/$(OS).mk which contains the default values for the
toolchain variables. This removes the need to pass HOST{CC/CXX} as
parameters from the high level make target or to default them to
gcc/g++ if unset.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian
Don't force the usage of the hardcoded toolchain values if those are
already set on the environment.
Note that as part of the change the definition of AS and LD is moved
after the setting of compiler related variables.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc:
This is a preparatory change for simplifying the setting of
HOST{CC/CXX} and allowing the Xen build system to pick the toolchain
variables from the environment.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulic
Hello,
Current Xen build system will ignore any toolchain related variables on
the environment when building (ie: CC, LD, CXX...), and the only way to
set those is to assign them directly on the make command line (ie: make
CC=foo CXX=bar ...).
The following series attempts to fix this, by removin
> On Sep 5, 2019, at 04:36, Lars Kurth wrote:
>
> On 05/09/2019, 09:33, "Juergen Gross" wrote:
>
>>On 05.09.19 10:14, Andrew Cooper wrote:
>>> On 05/09/2019 08:49, Lars Kurth wrote:
On 05/09/2019, 08:41, "Rich Persaud" wrote:
On Sep 5, 2019, at 03:19, 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 14:01, Jan Beulich
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 14:01, Jan Beulich wrote:
On 05.09.2019 13:39, Juergen Gross wrote:
As a prepar
> -Original Message-
> From: Jan Beulich
> Sent: 05 September 2019 15:30
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Alexandru Isaila
> ; PetrePircalabu ;
> Razvan Cojocaru
> ; Andrew Cooper ; Roger
> Pau Monne
> ; Volodymyr Babchuk ;
> George Dunlap
> ;
On 02.09.2019 16:50, Paul Durrant wrote:
> Now that there is a per-domain IOMMU-enable flag, which should be set if
> any device is going to be passed through, stop deferring page table
> construction until the assignment is done. Also don't tear down the tables
> again when the last device is de-a
Commit fd35f32b4b ("tools/x86emul: Use struct cpuid_policy in the
userspace test harnesses") didn't account for the dependencies of
cpuid-autogen.h to potentially change between incremental builds. In
particular the harness has a "run" goal which is supposed to be usable
independently of the rest o
Using memcpy() may result in multiple individual byte accesses
(dependening how memcpy() is implemented and how the resulting insns,
e.g. REP MOVSB, get carried out in hardware), which isn't what we
want/need for carrying out guest insns as correctly as possible. Fall
back to memcpy() only for misa
flight 141026 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141026/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 141000
Tests which did not succee
On 05.09.2019 15:52, Paul Durrant wrote:
>> From: Roger Pau Monne
>> Sent: 05 September 2019 14:27
>>
>> 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
On 05.09.2019 15:53, Paul Durrant wrote:
>> From: Xen-devel On Behalf Of Roger
>> Pau Monne
>> Sent: 05 September 2019 14:27
>>
>> 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 repor
> -Original Message-
> From: Xen-devel On Behalf Of Roger
> Pau Monne
> Sent: 05 September 2019 14:27
> To: xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Wei Liu ;
> Konrad Rzeszutek Wilk
> ; George Dunlap ; Andrew
> Cooper
> ; Ian Jackson ; Tim
> (Xen.org) ; Julien
> Grall
> -Original Message-
> From: Roger Pau Monne
> Sent: 05 September 2019 14:27
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; Ian Jackson
> ; Wei Liu
> ; Anthony Perard ; Andrew Cooper
> ;
> George Dunlap ; Jan Beulich ;
> Julien Grall
> ; Konrad Rzeszutek Wilk ;
> Stefano
flight 141013 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141013/
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. 139876
test-armhf-armhf-x
On 05/09/2019 14:09, Masami Hiramatsu wrote:
> On Thu, 5 Sep 2019 20:32:24 +0900
> Masami Hiramatsu wrote:
>
>> On Thu, 5 Sep 2019 08:54:17 +0100
>> Andrew Cooper wrote:
>>
>>> On 05/09/2019 02:49, Masami Hiramatsu wrote:
On Wed, 4 Sep 2019 12:54:55 +0100
Andrew Cooper wrote:
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
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.
The series can also be found at:
git://xenbits.xen.org/people/royger/xen.gi
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
On Thu, 5 Sep 2019 20:32:24 +0900
Masami Hiramatsu wrote:
> On Thu, 5 Sep 2019 08:54:17 +0100
> Andrew Cooper wrote:
>
> > On 05/09/2019 02:49, Masami Hiramatsu wrote:
> > > On Wed, 4 Sep 2019 12:54:55 +0100
> > > Andrew Cooper wrote:
> > >
> > >> On 04/09/2019 12:45, Masami Hiramatsu wrote:
>
On Thu, 5 Sep 2019 09:53:32 +0100
Andrew Cooper wrote:
> On 05/09/2019 09:26, Peter Zijlstra wrote:
> > On Thu, Sep 05, 2019 at 08:54:17AM +0100, Andrew Cooper wrote:
> >
> >> I don't know if you've spotted, but the prefix is a ud2a instruction
> >> followed by 'xen' in ascii.
> >>
> >> The KVM v
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 14:01, Jan Beulich wrote:
On 05.09.2019 13:39, Juergen Gross wrote:
As a preparation for per-cpu buffers do a little ref
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 14:01, Jan Beulich wrote:
On 05.09.2019 13:39, Juergen Gross wrote:
> As a preparation for per-cpu buffers do a little refactoring of the
> deb
On 05.09.19 14:20, Jan Beulich wrote:
On 05.09.2019 13:39, Juergen Gross wrote:
--- /dev/null
+++ b/xen/common/debugtrace.c
@@ -0,0 +1,181 @@
+/**
+ * debugtrace.c
+ *
+ * Debugtrace for Xen
+ */
+
+
+#include
+#include
On 05.09.19 14:22, Jan Beulich wrote:
On 05.09.2019 14:12, Juergen Gross wrote:
On 05.09.19 14:01, Jan Beulich wrote:
On 05.09.2019 13:39, Juergen Gross wrote:
As a preparation for per-cpu buffers do a little refactoring of the
debugtrace data: put the needed buffer admin data into the buffer
flight 141042 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141042/
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 05.09.2019 14:19, Juergen Gross wrote:
> On 05.09.19 14:13, Jan Beulich wrote:
>> On 05.09.2019 13:39, Juergen Gross wrote:
>>> --- a/xen/common/debugtrace.c
>>> +++ b/xen/common/debugtrace.c
>>> @@ -17,34 +17,40 @@
>>> #define DEBUG_TRACE_ENTRY_SIZE 1024
>>>
>>> /* Send output direct t
On 05.09.2019 14:12, Juergen Gross wrote:
> On 05.09.19 14:01, Jan Beulich wrote:
>> On 05.09.2019 13:39, Juergen Gross wrote:
>>> As a preparation for per-cpu buffers do a little refactoring of the
>>> debugtrace data: put the needed buffer admin data into the buffer as
>>> it will be needed for e
On 05.09.19 14:17, Jan Beulich wrote:
On 05.09.2019 13:39, Juergen Gross wrote:
After dumping the debugtrace buffer it is cleared. This results in some
entries not being printed in case the buffer is dumped again before
having wrapped.
While at it remove the trailing zero byte in the buffer as
On 05.09.2019 13:39, Juergen Gross wrote:
> --- /dev/null
> +++ b/xen/common/debugtrace.c
> @@ -0,0 +1,181 @@
> +/**
> + * debugtrace.c
> + *
> + * Debugtrace for Xen
> + */
> +
> +
> +#include
> +#include
> +#include
>
On 05.09.19 14:13, Jan Beulich wrote:
On 05.09.2019 13:39, Juergen Gross wrote:
--- a/xen/common/debugtrace.c
+++ b/xen/common/debugtrace.c
@@ -17,34 +17,40 @@
#define DEBUG_TRACE_ENTRY_SIZE 1024
/* Send output direct to console, or buffer it? */
-static volatile int debugtrace_send_to
On 05.09.2019 13:39, Juergen Gross wrote:
> After dumping the debugtrace buffer it is cleared. This results in some
> entries not being printed in case the buffer is dumped again before
> having wrapped.
>
> While at it remove the trailing zero byte in the buffer as it is no
> longer needed. Commi
On 05.09.2019 13:39, Juergen Gross wrote:
> --- a/xen/common/debugtrace.c
> +++ b/xen/common/debugtrace.c
> @@ -17,34 +17,40 @@
> #define DEBUG_TRACE_ENTRY_SIZE 1024
>
> /* Send output direct to console, or buffer it? */
> -static volatile int debugtrace_send_to_console;
> +static volatile bo
On 05.09.19 14:01, Jan Beulich wrote:
On 05.09.2019 13:39, Juergen Gross wrote:
As a preparation for per-cpu buffers do a little refactoring of the
debugtrace data: put the needed buffer admin data into the buffer as
it will be needed for each buffer. In order not to limit buffer size
switch the
On 05.09.2019 13:39, Juergen Gross wrote:
> As a preparation for per-cpu buffers do a little refactoring of the
> debugtrace data: put the needed buffer admin data into the buffer as
> it will be needed for each buffer. In order not to limit buffer size
> switch the related fields from unsigned int
On 05.09.2019 13:39, Juergen Gross wrote:
> debugtrace is normally writing trace entries into a single trace
> buffer. There are cases where this is not optimal, e.g. when hunting
> a bug which requires writing lots of trace entries and one cpu is
> stuck. This will result in other cpus filling the
On 9/5/19 12:01 PM, Roger Pau Monné wrote:
> On Thu, Sep 05, 2019 at 12:34:11PM +0200, George Dunlap wrote:
>>
>>
>>> On Sep 5, 2019, at 11:01 AM, Roger Pau Monne wrote:
>>>
>>> On Thu, Sep 05, 2019 at 11:52:59AM +0200, Jan Beulich wrote:
On 05.09.2019 11:34, Roger Pau Monne wrote:
> Curr
Now that the Xen special cases are gone nothing worth mentioning is
left in the arm64 file, so switch to use the
asm-generic version instead.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
Reviewed-by: Stefano Stabellini
---
arch/arm64/include/asm/Kbuild| 1 +
arch/arm64/incl
These routines are only used by swiotlb-xen, which cannot be modular.
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
---
arch/arm/xen/mm.c | 2 --
arch/x86/xen/mmu_pv.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 11d5ad
Now that we know we always have the dma-noncoherent.h helpers available
if we are on an architecture with support for non-coherent devices,
we can just call them directly, and remove the calls to the dma-direct
routines, including the fact that we call the dma_direct_map_page
routines but ignore th
No need for a no-op wrapper.
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index f81031f0c1c7..1190934098eb
arm and arm64 can just use xen_swiotlb_dma_ops directly like x86, no
need for a pointer indirection.
Signed-off-by: Christoph Hellwig
Reviewed-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
arch/arm/mm/dma-mapping.c| 3 ++-
arch/arm/xen/mm.c| 4
arch/arm64/mm/dma-map
Shared the duplicate arm/arm64 code in include/xen/arm/page-coherent.h.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/xen/page-coherent.h | 75
arch/arm64/include/asm/xen/page-coherent.h | 75
include/xen/arm/page-coherent.h| 80
Use the dma-noncoherent dev_is_dma_coherent helper instead of the home
grown variant. Note that both are always initialized to the same
value in arch_setup_dma_ops.
Signed-off-by: Christoph Hellwig
Reviewed-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
arch/arm/include/asm/dma-mapping.
There is no need to wrap the common version, just wire them up directly.
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 29 ++---
1 file changed, 2 insertions(+), 27 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/
xen_dma_map_page uses a different and more complicated check for foreign
pages than the other three cache maintainance helpers. Switch it to the
simpler pfn_valid method a well, and document the scheme with a single
improved comment in xen_dma_map_page.
Signed-off-by: Christoph Hellwig
Reviewed-
Calculate the required operation in the caller, and pass it directly
instead of recalculating it for each page, and use simple arithmetics
to get from the physical address to Xen page size aligned chunks.
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
---
arch/arm/xen/mm.c | 6
Another debugtrace enhancement I needed for core scheduling debugging,
plus some cleanup.
Changes in V5:
- several comments by Jan addressed (code: patches 1 and 4, commit
message of patch 3)
Changes in V4:
- replaced patch 1 (original one was committed, new one requested by
Jan Beulich)
- se
After dumping the debugtrace buffer it is cleared. This results in some
entries not being printed in case the buffer is dumped again before
having wrapped.
While at it remove the trailing zero byte in the buffer as it is no
longer needed. Commit b5e6e1ee8da59f introduced passing the number of
char
As a preparation for per-cpu buffers do a little refactoring of the
debugtrace data: put the needed buffer admin data into the buffer as
it will be needed for each buffer. In order not to limit buffer size
switch the related fields from unsigned int to unsigned long, as on
huge machines with RAM in
Instead of living in drivers/char/console.c move the debugtrace
related coding to a new file common/debugtrace.c
No functional change, code movement only.
Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
---
xen/common/Makefile| 1 +
xen/common/debugtrace.c| 181 +++
debugtrace is normally writing trace entries into a single trace
buffer. There are cases where this is not optimal, e.g. when hunting
a bug which requires writing lots of trace entries and one cpu is
stuck. This will result in other cpus filling the trace buffer and
finally overwriting the interest
Copy the arm64 code that uses the dma-direct/swiotlb helpers for DMA
on-coherent devices.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/device.h| 3 -
arch/arm/include/asm/xen/page-coherent.h | 72 +---
arch/arm/mm/dma-mapping.c| 8 +-
Hi Xen maintainers and friends,
please take a look at this series that cleans up the parts of swiotlb-xen
that deal with non-coherent caches.
Changes since v3:
- don't use dma_direct_alloc on x86
Changes since v2:
- further dma_cache_maint improvements
- split the previous patch 1 into 3 pat
On 05/09/2019 10:00, Jan Beulich wrote:
> On 04.09.2019 19:57, Andrew Cooper wrote:
>> AMD Pre-Fam17h CPUs "optimise" {F,}X{SAVE,RSTOR} by not saving/restoring
>> FOP/FIP/FDP if an x87 exception isn't pending. This causes an information
>> leak, CVE-2006-1056, and worked around by several OSes, in
On Thu, 5 Sep 2019 08:54:17 +0100
Andrew Cooper wrote:
> On 05/09/2019 02:49, Masami Hiramatsu wrote:
> > On Wed, 4 Sep 2019 12:54:55 +0100
> > Andrew Cooper wrote:
> >
> >> On 04/09/2019 12:45, Masami Hiramatsu wrote:
> >>> Hi,
> >>>
> >>> These patches allow x86 instruction decoder to decode
>
On Thu, Sep 05, 2019 at 12:34:11PM +0200, George Dunlap wrote:
>
>
> > On Sep 5, 2019, at 11:01 AM, Roger Pau Monne wrote:
> >
> > On Thu, Sep 05, 2019 at 11:52:59AM +0200, Jan Beulich wrote:
> >> On 05.09.2019 11:34, Roger Pau Monne wrote:
> >>> Current libxl code will always enable Hardware A
On 05.09.19 12:28, Jan Beulich wrote:
On 04.09.2019 15:46, Juergen Gross wrote:
@@ -25,33 +26,63 @@ struct debugtrace_data {
};
static struct debugtrace_data *dt_data;
+static DEFINE_PER_CPU(struct debugtrace_data *, dt_cpu_data);
-static unsigned int debugtrace_kilobytes = 128;
+sta
On 05/09/2019 11:32, Jan Beulich wrote:
> On 05.09.2019 12:01, Roger Pau Monné wrote:
>> On Thu, Sep 05, 2019 at 11:52:59AM +0200, Jan Beulich wrote:
>>> On 05.09.2019 11:34, Roger Pau Monne wrote:
Current libxl code will always enable Hardware Assisted Paging (HAP),
expecting that the h
> On Sep 5, 2019, at 11:01 AM, Roger Pau Monne wrote:
>
> On Thu, Sep 05, 2019 at 11:52:59AM +0200, Jan Beulich wrote:
>> On 05.09.2019 11:34, Roger Pau Monne wrote:
>>> Current libxl code will always enable Hardware Assisted Paging (HAP),
>>> expecting that the hypervisor will fallback to shad
On 05.09.2019 12:01, Roger Pau Monné wrote:
> On Thu, Sep 05, 2019 at 11:52:59AM +0200, Jan Beulich wrote:
>> On 05.09.2019 11:34, 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 no
1 - 100 of 140 matches
Mail list logo
