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
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
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
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
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)
-
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
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
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
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.
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
> -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
> ;
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
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 +
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
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
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|
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
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
---
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
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 |
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
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
>
> -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
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 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 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
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:
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
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:
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
> -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
>
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
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
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
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
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,
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
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
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
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:
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
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
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
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
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
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
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
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
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:
>
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
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
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 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
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
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
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
> 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:
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
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
> >
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
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)
> 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
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
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
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
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
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
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
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
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
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
> >
> 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:
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:
> -
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
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
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
-
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,
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
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
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
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
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
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
> >
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
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
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
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
>
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
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
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
Despite %.12s properly limiting the number of characters read from
ident[], gcc 9 (at least up to 9.2.0) warns about the strings not
being nul-terminated:
test-cpu-policy.c:64:18: error: '%.12s' directive argument is not a
nul-terminated string [-Werror=format-overflow=]
64 |
Hi Sergey,
On 15.08.19 12:17, Sergey Dyasli wrote:
Hi Juergen,
The latest round of testing revealed the following 3 Xen crashes:
1. vcpu_sleep_sync() <-- vlapic_init_sipi_action()
This was seen multiple times. It tends to happen on large Windows Server
VMs (>= 12 vCPUs).
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 version was added in c/s 6c86eedc206dd1f9d37a2796faa8e6f2278215d2
While the Xen one disassebles to valid instructions,
On 2019-09-05 18:19, Andrew Cooper wrote:
On 05/09/2019 09:00, Lars Kurth wrote:
IMPORTANT: I had a few additions to the agenda, but do not know WHO
added these. I believe one was Juergen. Who added the items related to
MA Youngs patches?
Steven Haigh I believe.
Booting fedora guests is
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:
>
> Forgive me asking, but why is this put up as an agenda item here?
> IMO this is the kind of thing
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
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1256,29 +1256,26 @@ static unsigned int sh_min_allocation(co
1 - 100 of 142 matches
Mail list logo
