branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-shadow
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qem
xen/sched-if.h is included in multiple sources where it isn't directly
needed. Remove those #include statements.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
---
Carved out from patch 7 of my core scheduling series
---
xen/arch/x86/acpi/cpu_idle.c | 1 -
xen/arch/x86/cpu/mcheck/m
On 04.09.19 15:48, Jan Beulich wrote:
On 09.08.2019 16:57, Juergen Gross wrote:
This prepares support of larger scheduling granularities, e.g. core
scheduling.
While at it move sched_has_urgent_vcpu() from include/asm-x86/cpuidle.h
into schedule.c removing the need for including sched-if.h in
c
On 05.09.2019 04:32, Rich Persaud wrote:
> Agenda item: Domain name service for nested virt and disaggregation
>
> (text based on draft by Daniel Smith, who will speak to this agenda item)
>
> If a future, minimal "L0 Xen" hypervisor can be optimized for nested
> virtualization in greenfield d
On 05.09.2019 09:06, Juergen Gross wrote:
> xen/sched-if.h is included in multiple sources where it isn't directly
> needed. Remove those #include statements.
>
> Suggested-by: Jan Beulich
> Signed-off-by: Juergen Gross
Given the tag in place already I'm not sure this is needed, but just
in cas
On 05/09/2019 07:14, Jan Beulich wrote:
> 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 [
On 05/09/2019 08:21, Jan Beulich wrote:
> On 05.09.2019 09:06, Juergen Gross wrote:
>> xen/sched-if.h is included in multiple sources where it isn't directly
>> needed. Remove those #include statements.
>>
>> Suggested-by: Jan Beulich
>> Signed-off-by: Juergen Gross
> Given the tag in place alrea
flight 141005 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141005/
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
At 09:55 +0200 on 04 Sep (1567590940), Jan Beulich wrote:
> Commit 2634b997af ("x86/shadow: don't enable shadow mode with too small
> a shadow allocation") was incomplete: The adjustment done there to
> shadow_enable() is also needed in shadow_one_bit_enable(). The (new)
> problem report was (appar
On 05.09.2019 09:13, Juergen Gross wrote:
> On 04.09.19 15:48, Jan Beulich wrote:
>> On 09.08.2019 16:57, Juergen Gross wrote:
>>> This prepares support of larger scheduling granularities, e.g. core
>>> scheduling.
>>>
>>> While at it move sched_has_urgent_vcpu() from include/asm-x86/cpuidle.h
>>>
> On Sep 5, 2019, at 03:19, Jan Beulich wrote:
>
>> On 05.09.2019 04:32, Rich Persaud wrote:
>> Agenda item: Domain name service for nested virt and disaggregation
>>
>> (text based on draft by Daniel Smith, who will speak to this agenda item)
>>
>> If a future, minimal "L0 Xen" hypervisor ca
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 where you would send a proposal and
> request feedback by email first, and put
On 05.09.2019 09:41, Rich Persaud wrote:
> If Xen community call topics are limited to escalations of xen-devel threads,
> then a new thread can be created for this topic. Xen community calls have
> also provided real-time, interactive feedback on candidate proposals, along
> with guidance on ar
On 05.09.19 09:41, Rich Persaud wrote:
On Sep 5, 2019, at 03:19, Jan Beulich wrote:
On 05.09.2019 04:32, Rich Persaud wrote:
Agenda item: Domain name service for nested virt and disaggregation
(text based on draft by Daniel Smith, who will speak to this agenda item)
If a future, minimal "L0
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
>>> xen-cpuid which has XEN_EMULATE_PREFIX, and prohibit
>>> kprobes to pr
On 05/09/2019, 08:50, "Jan Beulich" wrote:
On 05.09.2019 09:41, Rich Persaud wrote:
> If Xen community call topics are limited to escalations of xen-devel
threads, then a new thread can be created for this topic. Xen community calls
have also provided real-time, interactive feedback
Hi,
On 02/09/2019 09:11, Alexandru Stefan ISAILA wrote:
> By default the sve bits are not set.
While altp2m is currently only supported for x86 (though I am aware of
some port for Arm), this patch extends an interface that is meant to be
arch-agnostic. So what does "sve" stands for?
> diff --g
On 05.09.19 10:00, Lars Kurth wrote:
On 05/09/2019, 08:50, "Jan Beulich" wrote:
On 05.09.2019 09:41, Rich Persaud wrote:
> If Xen community call topics are limited to escalations of xen-devel
threads, then a new thread can be created for this topic. Xen community calls have
also
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 where you would send a proposal and
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 currently in a very broken state.
~Andrew
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, th
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 curr
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
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:
>> >
>> > Forgive me as
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 version was added in c/s 6c86eedc206dd1f9d37a2796faa8e6f2278215d2
> Whil
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, including Xen. AMD
> Fam17h CPUs no longer hav
On Thu, Sep 05, 2019 at 09:53:32AM +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
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 05/09/2019 10:26, Peter Zijlstra wrote:
> On Thu, Sep 05, 2019 at 09:53:32AM +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
> -Original Message-
[snip]
> -void libxl__arch_domain_create_info_setdefault(libxl__gc *gc,
> - libxl_domain_create_info
> *c_info)
> +int libxl__arch_domain_create_info_setdefault(libxl__gc *gc,
> +
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 not
> available. With the changes to the domain builder that's not the case
> any longer, and the hypervisor will rai
flight 141003 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141003/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail REGR. vs. 140999
test-amd64-amd64-xl-
On Thu, Sep 05, 2019 at 11:40:19AM +0200, Paul Durrant wrote:
> > -Original Message-
> [snip]
> > -void libxl__arch_domain_create_info_setdefault(libxl__gc *gc,
> > - libxl_domain_create_info
> > *c_info)
> > +int libxl__arch_domain_create_info
On 05/09/2019 10:52, 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 not
>> available. With the changes to the domain builder that's not the c
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 not
> > available. With the changes to the domain
On 04.09.2019 15:46, Juergen Gross wrote:
> --- a/xen/common/debugtrace.c
> +++ b/xen/common/debugtrace.c
> @@ -15,35 +15,41 @@
> #include
>
> /* Send output direct to console, or buffer it? */
> -static volatile int debugtrace_send_to_console;
> +static volatile bool debugtrace_send_to_consol
flight 141009 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141009/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-build fail in 140941 REGR. vs. 139910
build-amd64
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;
> +static unsigned long debugtrace_by
On 05.09.19 12:06, Jan Beulich wrote:
On 04.09.2019 15:46, Juergen Gross wrote:
--- a/xen/common/debugtrace.c
+++ b/xen/common/debugtrace.c
@@ -15,35 +15,41 @@
#include
/* Send output direct to console, or buffer it? */
-static volatile int debugtrace_send_to_console;
+static volatile b
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
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.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 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 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/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
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
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 +-
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
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 +++
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
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
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-
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/
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
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
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
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
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
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
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 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.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:
> --- 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.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.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:
> --- /dev/null
> +++ b/xen/common/debugtrace.c
> @@ -0,0 +1,181 @@
> +/**
> + * debugtrace.c
> + *
> + * Debugtrace for Xen
> + */
> +
> +
> +#include
> +#include
> +#include
>
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 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
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.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.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.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: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 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 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 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.
The series can also be found at:
git://xenbits.xen.org/people/royger/xen.gi
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 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:
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
> -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
> -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
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
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
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
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
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
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
> -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 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
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 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:
>
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
1 - 100 of 140 matches
Mail list logo
