On Wed, Apr 18, 2018 at 11:10:58AM +0100, Roger Pau Monné wrote:
> On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko wrote:
> > On 04/18/2018 10:35 AM, Roger Pau Monné wrote:
> > > On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote:
> > > > On 04/17/2018 11:57 P
On Wed, Apr 18, 2018 at 11:55:26AM +0100, Roger Pau Monné wrote:
> On Wed, Apr 18, 2018 at 01:39:35PM +0300, Oleksandr Andrushchenko wrote:
> > On 04/18/2018 01:18 PM, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On
flight 74634 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74634/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail blocked
in 74590
baseline versio
On Thu, Apr 19, 2018 at 09:05:35AM -0600, Jan Beulich wrote:
> >>> On 19.04.18 at 16:28, wrote:
> > Commit 0d31d16 (x86/setup: do not relocate Xen over current Xen image
> > placement) disallowed src/dst images overlaps when relocating Xen image.
> > Though it deliberately allowed destination regi
HVM's MMIO cache only has a capacity of three entries. Once running out
of entries, hvmemul_linear_mmio_access() will return
X86EMUL_UNHANDLEABLE. Since gathers are an iterative process anyway,
simply commit the portion of work done in this and hypothetical similar
cases, exiting back to guest cont
On Thu, Apr 19, 2018 at 05:22:28PM +0100, Wei Liu wrote:
> On Thu, Apr 19, 2018 at 05:14:38PM +0100, Andrew Cooper wrote:
> > On 19/04/18 15:54, Wei Liu wrote:
> > > On Thu, Apr 19, 2018 at 01:01:53PM +0200, Juergen Gross wrote:
> > >> On 19/04/18 12:47, Jan Beulich wrote:
> > >> On 19.04.18 at
>>> On 20.04.18 at 11:15, wrote:
> On Thu, Apr 19, 2018 at 09:05:35AM -0600, Jan Beulich wrote:
>> >>> On 19.04.18 at 16:28, wrote:
>> > @@ -1019,6 +1020,15 @@ void __init noreturn __start_xen(unsigned long
>> > mbi_p)
>> > bootsym(trampoline_xen_phys_start) = e;
>> >
>> >
On 20/04/18 10:28, Roger Pau Monné wrote:
> On Thu, Apr 19, 2018 at 05:22:28PM +0100, Wei Liu wrote:
>> On Thu, Apr 19, 2018 at 05:14:38PM +0100, Andrew Cooper wrote:
>>> On 19/04/18 15:54, Wei Liu wrote:
On Thu, Apr 19, 2018 at 01:01:53PM +0200, Juergen Gross wrote:
> On 19/04/18 12:47, J
>>> On 19.04.18 at 17:44, wrote:
> On 18/04/18 23:15, Stefano Stabellini wrote:
>> --- a/xen/drivers/passthrough/Kconfig
>> +++ b/xen/drivers/passthrough/Kconfig
>> @@ -1,3 +1,5 @@
>>
>> config HAS_PASSTHROUGH
>> bool
>> +
>> +source "drivers/passthrough/arm/Kconfig"
>
> Can't we load a
Hi all,
We are pleased to announce an update of Intel GVT-g for Xen.
Intel GVT-g is a full GPU virtualization solution with mediated pass-through,
starting from 4th generation Intel Core(TM) processors with Intel processor
graphics. A virtual GPU instance is maintained for each VM, with par
>>> On 20.04.18 at 00:43, wrote:
> On Thu, 19 Apr 2018, Jan Beulich wrote:
>> >>> On 19.04.18 at 00:15, wrote:
>> > --- /dev/null
>> > +++ b/xen/drivers/passthrough/arm/Kconfig
>> > @@ -0,0 +1,7 @@
>> > +
>> > +config HAS_SMMUv2
>> > + bool "ARM SMMUv2 driver"
>> > + default y
>> > + depends o
On 20/04/18 11:33, Andrew Cooper wrote:
> On 20/04/18 10:28, Roger Pau Monné wrote:
>> On Thu, Apr 19, 2018 at 05:22:28PM +0100, Wei Liu wrote:
>>> On Thu, Apr 19, 2018 at 05:14:38PM +0100, Andrew Cooper wrote:
On 19/04/18 15:54, Wei Liu wrote:
> On Thu, Apr 19, 2018 at 01:01:53PM +0200, J
Commit 0d31d16 (x86/setup: do not relocate Xen over current Xen image
placement) disallowed src/dst images overlaps when relocating Xen image.
Though it deliberately allowed destination region between __image_base__
and (__image_base__ + XEN_IMG_OFFSET) overlaps with the end of source
image. And he
On Fri, Apr 20, 2018 at 03:32:22AM -0600, Jan Beulich wrote:
> >>> On 20.04.18 at 11:15, wrote:
> > On Thu, Apr 19, 2018 at 09:05:35AM -0600, Jan Beulich wrote:
> >> >>> On 19.04.18 at 16:28, wrote:
> >> > @@ -1019,6 +1020,15 @@ void __init noreturn __start_xen(unsigned long
> >> > mbi_p)
> >> >
>>> On 20.04.18 at 01:22, wrote:
> On Thu, 19 Apr 2018, Jan Beulich wrote:
>> >>> On 19.04.18 at 00:15, wrote:
>> > Add a Xen build target to count the lines of code of the source files
>> > built. Uses `cloc' to do the job.
>> >
>> > Generate the list of source files from the %.o targets, appen
On 20/04/18 00:04, Boris Ostrovsky wrote:
> On 04/19/2018 02:18 PM, Andrew Cooper wrote:
>> On 19/04/18 16:54, Natarajan, Janakarajan wrote:
>>> On 4/13/2018 12:57 PM, Andrew Cooper wrote:
On 04/04/18 00:01, Janakarajan Natarajan wrote:
> @@ -63,6 +64,54 @@ avic_get_physical_id_entry(struc
>>> On 19.04.18 at 20:18, wrote:
> On 19/04/18 16:54, Natarajan, Janakarajan wrote:
>> On 4/13/2018 12:57 PM, Andrew Cooper wrote:
>>> On 04/04/18 00:01, Janakarajan Natarajan wrote:
@@ -63,6 +64,54 @@ avic_get_physical_id_entry(struct svm_domain *d,
unsigned int index)
return
Philippe Mathieu-Daudé writes ("Re: [Qemu-devel] [PATCH 14/16] os-posix:
cleanup: Replace fprintf with error_report in remaining call sites"):
> On 04/19/2018 01:45 PM, Ian Jackson wrote:
> > -fprintf(stderr, "Change of process name not supported by your OS\n");
> > +error_report("Change o
>>> On 20.04.18 at 08:40, wrote:
> --- a/tools/firmware/xen-dir/Makefile
> +++ b/tools/firmware/xen-dir/Makefile
> @@ -41,16 +41,14 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES) FORCE
> $(D): linkfarm.stamp
> $(MAKE) -C $(D)/xen distclean
>
> -.PHONY: shim-%config
> -shim-%config: $(D) FORC
Hello
Please use "reply-all" in the future.
On Tue, Apr 10, 2018 at 09:48:01AM +, Peter McLaren wrote:
>
>
> Peter McLaren
>
>
>
> From: Wei Liu
> Sent: Tuesday, 10 April 2018 7:01 PM
> To: Peter McLaren
> Cc: Wei Liu; Xen-devel
> Subject: Re: [Xen-devel]
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.17-rc2-tag
xen: fixes and one header update for 4.17-rc2
It contains some fixes of kmalloc() flags, one fix of the xenbus driver
and an update of the pv sound driver interface neede
The overall idea of this patch is to add a generic fault injection facility
to Xen, which later can be used in various places by different Xen parts.
Core implementation ideas:
- The facility build is controlled by boolean config
CONFIG_XEN_FAULT_INJECTION option ("N" by default).
- All fault
This patch adds wrapper helpers around generic Xen fault inject
facility.
The major reason is to keep all the module fault injection directories
in a dedicated subdirectory instead of Xen fault inject root.
IOW, when using these helpers, per-device and named by device name
fault injection control
This patch adds wrapper helpers around generic Xen fault inject facility.
The major reason is to keep all the module fault injection directories
in a dedicated subdirectory instead of Xen fault inject root.
IOW, when using these helpers, per-device and named by device name fault
injection control
This series adds a facility, which can be used to instrument Xen code with
fault injections.
It is based "Fault injection capabilities infrastructure" described here:
- Documentation/fault-injection/fault-injection.txt
First patch adds a generic facility to use anywhere in Xen.
When using it all t
On 20/04/18 12:47, Stanislav Kinsburskii wrote:
> The overall idea of this patch is to add a generic fault injection facility
> to Xen, which later can be used in various places by different Xen parts.
>
> Core implementation ideas:
>
> - The facility build is controlled by boolean config
> CON
Hi,
When I upgrade to Xen 4.11, I got the following when creating any guest:
(XEN)_event_channel.c:319:d0v3_EVTCHNOP_failure:_domain_1,_error_-22
(XEN)_event_channel.c:319:d0v3_EVTCHNOP_failure:_domain_1,_error_-22
(XEN)_event_channel.c:319:d0v3_EVTCHNOP_failure:_domain_1,_error_-22
(XEN)_event_c
On 20/04/18 12:47, Stanislav Kinsburskii wrote:
> This patch adds wrapper helpers around generic Xen fault inject facility.
> The major reason is to keep all the module fault injection directories
> in a dedicated subdirectory instead of Xen fault inject root.
>
> IOW, when using these helpers, pe
On 04/20/2018 10:19 AM, Daniel Vetter wrote:
On Wed, Apr 18, 2018 at 11:10:58AM +0100, Roger Pau Monné wrote:
On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko wrote:
On 04/18/2018 10:35 AM, Roger Pau Monné wrote:
On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenk
On 20/04/18 12:47, Stanislav Kinsburskii wrote:
> This patch adds wrapper helpers around generic Xen fault inject
> facility.
> The major reason is to keep all the module fault injection directories
> in a dedicated subdirectory instead of Xen fault inject root.
>
> IOW, when using these helpers,
On 20/04/18 12:28, Jan Beulich wrote:
On 20.04.18 at 08:40, wrote:
>> --- a/tools/firmware/xen-dir/Makefile
>> +++ b/tools/firmware/xen-dir/Makefile
>> @@ -41,16 +41,14 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES) FORCE
>> $(D): linkfarm.stamp
>> $(MAKE) -C $(D)/xen distclean
>>
>> -.P
>>> On 20.04.18 at 14:13, wrote:
> On 20/04/18 12:28, Jan Beulich wrote:
> On 20.04.18 at 08:40, wrote:
>>> --- a/tools/firmware/xen-dir/Makefile
>>> +++ b/tools/firmware/xen-dir/Makefile
>>> @@ -41,16 +41,14 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES) FORCE
>>> $(D): linkfarm.stamp
>>>
CPU up flow is currently used during the initial boot to start secondary
CPUs. However, the same flow should be used for CPU hotplug, e.g. when
hotplugging secondary CPUs within the resume procedure (resume from the
suspend to RAM). Therefore, prefixes __initdata and __init had to be removed
from f
In existing code the paging for non-boot CPUs is setup only on boot. The
setup is triggered from start_xen() after all CPUs are brought online.
In other words, the initialization of VTCR_EL2 register is done out of the
cpu_up/start_secondary() control flow. However, the cpu_up flow is also used
to
When a CPU is hot-unplugged the maintenance interrupt has to be
released in order to free the memory that was allocated when the CPU
was hotplugged and interrupt requested. The interrupt was requested
using request_irq() which is called from start_secondary->
init_maintenance_interrupt.
Signed-off
Non-boot pCPUs are being hot-unplugged during the system suspend to
RAM and hotplugged during the resume. When non-boot pCPUs are
hot-unplugged the interrupts that were targeted to them are migrated
to the boot pCPU.
On suspend, each guest could have its own wake-up devices/interrupts
(passthrough)
Guests attempt to write into these registers on resume (for example Linux).
Without this patch a data abort exception will be raised to the guest.
This patch handles the write access by ignoring it, but only if the value
to be written is zero. This should be fine because reading these registers
is
This patch set contains fixes that are required as precondition for suspend to
RAM support, including the CPU hotplug which is required to suspend non-boot
CPUs.
The first two patches in this series:
1) xen/arm64: Added handling of the trapped access to OSLSR register
2) xen/arm: Ignore write to GI
Linux/dom0 accesses OSLSR register when saving CPU context during the
suspend procedure. Xen traps access to this register, but has no handling
for it. Consequently, Xen injects undef exception to linux, causing it to
crash. This patch adds handling of the trapped access to OSLSR as ro/raz.
Signed
The memory allocated in setup_cpu_sibling_map() when a CPU is hotplugged
has to be freed when the CPU is hot-unplugged. This is done in
remove_cpu_sibling_map() and called from __cpu_disable() on CPU hot-unplug.
Signed-off-by: Mirela Simonovic
---
CC: Stefano Stabellini
CC: Julien Grall
---
x
Checking CPU errata should be done only when a CPU is initially booted.
It is assumed that the CPU which is hotplugged after the system/Xen boots,
was initially hotplugged during the system/Xen boot, so errata is checked
by each CPU only once, on boot.
Signed-off-by: Mirela Simonovic
---
CC: Ste
During the system suspend to RAM non-boot CPUs will be hotplugged.
This will be triggered via disable_nonboot_cpus() call. When
hotplugged the CPU will end up in an infinite wfi loop in stop_cpu().
This patch adds PSCI CPU_OFF call to the EL3 with the aim to get powered
down the calling CPU during
When a CPU is hot-unplugged timer interrupts have to be released
in order to free the memory that was allocated when the interrupts
were requested (using request_irq()). The request_irq is called
for each timer interrupt when the CPU gets hotplugged
(start_secondary->init_timer_interrupt->request_i
>>> On 20.04.18 at 11:25, wrote:
> @@ -7692,12 +7693,23 @@ x86_emulate(
> ea.mem.off + (idx << state->sib_scale),
> (void *)mmvalp + i * op_bytes, op_bytes,
> ctxt);
> if ( rc != X86EMUL_OKAY )
> +{
>
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 20 April 2018 13:34
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-devel de...@lists.xenproject.org>
> Subject: another state machine issue? (was: [PATCH] x86emul: adjust
> handling of AVX2 gathers)
>
> >>> On 20.0
On Thu, Apr 19, 2018 at 4:09 PM, Simon Gaiser
wrote:
> Jason Andryuk:
>> On Thu, Apr 19, 2018 at 2:10 PM, Simon Gaiser
>> wrote:
>>> Jason Andryuk:
A toolstack may delete the vif frontend and backend xenstore entries
while xen-netfront is in the removal code path. In that case, the
>>>
On 20/04/18 13:33, Jan Beulich wrote:
On 20.04.18 at 11:25, wrote:
>> @@ -7692,12 +7693,23 @@ x86_emulate(
>> ea.mem.off + (idx << state->sib_scale),
>> (void *)mmvalp + i * op_bytes, op_bytes,
>> ctxt);
>> if (
On 04/20/18 12:59, Juergen Gross wrote:
On 20/04/18 12:47, Stanislav Kinsburskii wrote:
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index c1f98f3..483fc16 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -77,3 +77,10 @@ config XEN_PVH
bool "Support for running
On 04/20/18 13:25, Juergen Gross wrote:
On 20/04/18 12:47, Stanislav Kinsburskii wrote:
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 8918466..5cc9acd 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -465,6 +465,14 @@ config XEN_NETDEV_BACKEND
compile this d
On 04/20/18 13:28, Juergen Gross wrote:
On 20/04/18 12:47, Stanislav Kinsburskii wrote:
This patch adds wrapper helpers around generic Xen fault inject
facility.
The major reason is to keep all the module fault injection directories
in a dedicated subdirectory instead of Xen fault inject root.
Ian Jackson writes:
> This allows the caller to specify a uid and gid to use, even if there
> is no corresponding password entry. This will be useful in certain
> Xen configurations.
>
> We don't support just -runas because: (i) deprivileging without
> calling setgroups would be ineffective (ii
On 20/04/18 14:52, stask...@amazon.com wrote:
> On 04/20/18 13:25, Juergen Gross wrote:
>> On 20/04/18 12:47, Stanislav Kinsburskii wrote:
>>> + for (fi = 0; fi < XENVIF_FI_MAX; fi++) {
>>> + vfi->faults[fi] = xen_fi_dir_add(vfi->dir,
>>> + xenvif_fi_names[fi]);
>> How does
On 20/04/18 14:22, Jan Beulich wrote:
On 20.04.18 at 14:13, wrote:
>> On 20/04/18 12:28, Jan Beulich wrote:
>> On 20.04.18 at 08:40, wrote:
--- a/tools/firmware/xen-dir/Makefile
+++ b/tools/firmware/xen-dir/Makefile
@@ -41,16 +41,14 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FIL
On 04/20/18 15:00, Juergen Gross wrote:
On 20/04/18 14:52, stask...@amazon.com wrote:
On 04/20/18 13:25, Juergen Gross wrote:
On 20/04/18 12:47, Stanislav Kinsburskii wrote:
+ for (fi = 0; fi < XENVIF_FI_MAX; fi++) {
+ vfi->faults[fi] = xen_fi_dir_add(vfi->dir,
+ xenvi
PVH guests with 4GB of RAM or more get a memory map like the
following:
0x00 - 0x00fee0 RAM
0x00fee0 - 0x01 RESERVED
0x00fc009000 - 0x00fc009040 ACPI
0x00fc00 - 0x00fc001000 ACPI
0x00fc001000 - 0x00fc009000 ACPI
0x01 -
On 20/04/18 15:52, Roger Pau Monne wrote:
> PVH guests with 4GB of RAM or more get a memory map like the
> following:
>
> 0x00 - 0x00fee0 RAM
> 0x00fee0 - 0x01 RESERVED
> 0x00fc009000 - 0x00fc009040 ACPI
> 0x00fc00 - 0x00fc001000 ACPI
> 0
>>> On 20.04.18 at 15:52, wrote:
> PVH guests with 4GB of RAM or more get a memory map like the
> following:
>
> 0x00 - 0x00fee0 RAM
> 0x00fee0 - 0x01 RESERVED
> 0x00fc009000 - 0x00fc009040 ACPI
> 0x00fc00 - 0x00fc001000 ACPI
> 0x00f
On Fri, Apr 20, 2018 at 08:01:35AM -0600, Jan Beulich wrote:
> >>> On 20.04.18 at 15:52, wrote:
> > PVH guests with 4GB of RAM or more get a memory map like the
> > following:
> >
> > 0x00 - 0x00fee0 RAM
> > 0x00fee0 - 0x01 RESERVED
> > 0x00fc009000 - 0
Commit 5fcb26e69e ("x86/HVM: don't retain emulated insn cache when
exiting back to guest") didn't go quite far enough: The insn emulator
may itself decide to return X86EMUL_RETRY (currently for certain
CMPXCHG failures and AVX2 gather insns), in which case we'd also exit
back to guest context. Tie
On 20/04/18 16:19, Jan Beulich wrote:
> Commit 5fcb26e69e ("x86/HVM: don't retain emulated insn cache when
> exiting back to guest") didn't go quite far enough: The insn emulator
> may itself decide to return X86EMUL_RETRY (currently for certain
> CMPXCHG failures and AVX2 gather insns), in which c
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 20 April 2018 15:19
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; Juergen Gross
> Subject: [PATCH] x86/HVM: never retain emulated insn cache when exiting
> back to guest
>
> Commit 5fcb26e69e ("x86/HVM:
>>> On 20.04.18 at 16:15, wrote:
> On Fri, Apr 20, 2018 at 08:01:35AM -0600, Jan Beulich wrote:
>> >>> On 20.04.18 at 15:52, wrote:
>> > PVH guests with 4GB of RAM or more get a memory map like the
>> > following:
>> >
>> > 0x00 - 0x00fee0 RAM
>> > 0x00fee0 - 0x01
On Fri, Apr 20, 2018 at 08:25:41AM -0600, Jan Beulich wrote:
> >>> On 20.04.18 at 16:15, wrote:
> > On Fri, Apr 20, 2018 at 08:01:35AM -0600, Jan Beulich wrote:
> >> >>> On 20.04.18 at 15:52, wrote:
> >> > PVH guests with 4GB of RAM or more get a memory map like the
> >> > following:
> >> >
> >>
>>> On 20.04.18 at 16:31, wrote:
> AFAICT the only reserved pages for PVH are the HVM special pages, so
> I've changed the memory map builder to only report those as reserved,
> here is the resulting memory map:
>
> 0x00 - 0x00fc00 RAM
> 0x00feff8000 - 0x00ff00 RES
PVH guests with 4GB of RAM or more get a memory map like the
following:
0x00 - 0x00fee0 RAM
0x00fee0 - 0x01 RESERVED
0x00fc009000 - 0x00fc009040 ACPI
0x00fc00 - 0x00fc001000 ACPI
0x00fc001000 - 0x00fc009000 ACPI
0x01 -
On 20/04/18 16:57, Roger Pau Monne wrote:
> PVH guests with 4GB of RAM or more get a memory map like the
> following:
>
> 0x00 - 0x00fee0 RAM
> 0x00fee0 - 0x01 RESERVED
> 0x00fc009000 - 0x00fc009040 ACPI
> 0x00fc00 - 0x00fc001000 ACPI
> 0
hvm_domain_initialise() may call this with nr being zero, which triggers
the "does not cross L3 boundary" check.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5475,7 +5475,7 @@ void destroy_perdomain_mapping(struct do
ASSERT(va >= PERDOMAIN_VIRT_START &&
On 20/04/18 15:31, Roger Pau Monné wrote:
> On Fri, Apr 20, 2018 at 08:25:41AM -0600, Jan Beulich wrote:
> On 20.04.18 at 16:15, wrote:
>>> On Fri, Apr 20, 2018 at 08:01:35AM -0600, Jan Beulich wrote:
>>> On 20.04.18 at 15:52, wrote:
> PVH guests with 4GB of RAM or more get a memory m
On 20/04/18 17:09, Andrew Cooper wrote:
> On 20/04/18 15:31, Roger Pau Monné wrote:
>> On Fri, Apr 20, 2018 at 08:25:41AM -0600, Jan Beulich wrote:
>> On 20.04.18 at 16:15, wrote:
On Fri, Apr 20, 2018 at 08:01:35AM -0600, Jan Beulich wrote:
On 20.04.18 at 15:52, wrote:
>> PV
Adding xen-devel and the Linux Xen maintainers.
Summary: Some Xen users (and maybe others) are hitting a BUG in
__radix_tree_lookup() under do_swap_page() - example backtrace is
provided at the end. Matthew Wilcox provided a band-aid patch that
prints errors like the following instead of triggeri
On 20/04/18 16:03, Jan Beulich wrote:
> hvm_domain_initialise() may call this with nr being zero, which triggers
> the "does not cross L3 boundary" check.
>
> Signed-off-by: Jan Beulich
Is this the correct fix?
Its unclear what the call to create_perdomain_mapping() is doing, but it
is the sole
On 20/04/18 16:20, Jason Andryuk wrote:
> Adding xen-devel and the Linux Xen maintainers.
>
> Summary: Some Xen users (and maybe others) are hitting a BUG in
> __radix_tree_lookup() under do_swap_page() - example backtrace is
> provided at the end. Matthew Wilcox provided a band-aid patch that
> p
>>> On 20.04.18 at 17:21, wrote:
> On 20/04/18 16:03, Jan Beulich wrote:
>> hvm_domain_initialise() may call this with nr being zero, which triggers
>> the "does not cross L3 boundary" check.
>>
>> Signed-off-by: Jan Beulich
>
> Is this the correct fix?
>
> Its unclear what the call to create_p
On Fri, Apr 20, 2018 at 04:09:46PM +0100, Andrew Cooper wrote:
> On 20/04/18 15:31, Roger Pau Monné wrote:
> > On Fri, Apr 20, 2018 at 08:25:41AM -0600, Jan Beulich wrote:
> > On 20.04.18 at 16:15, wrote:
> >>> On Fri, Apr 20, 2018 at 08:01:35AM -0600, Jan Beulich wrote:
> >>> On 20.04.18
On 20/04/18 16:25, Andrew Cooper wrote:
> On 20/04/18 16:20, Jason Andryuk wrote:
>> Adding xen-devel and the Linux Xen maintainers.
>>
>> Summary: Some Xen users (and maybe others) are hitting a BUG in
>> __radix_tree_lookup() under do_swap_page() - example backtrace is
>> provided at the end. Ma
On 20/04/18 16:27, Jan Beulich wrote:
On 20.04.18 at 17:21, wrote:
>> On 20/04/18 16:03, Jan Beulich wrote:
>>> hvm_domain_initialise() may call this with nr being zero, which triggers
>>> the "does not cross L3 boundary" check.
>>>
>>> Signed-off-by: Jan Beulich
>> Is this the correct fix?
>>> On 20.04.18 at 17:25, wrote:
> On 20/04/18 16:20, Jason Andryuk wrote:
>> Adding xen-devel and the Linux Xen maintainers.
>>
>> Summary: Some Xen users (and maybe others) are hitting a BUG in
>> __radix_tree_lookup() under do_swap_page() - example backtrace is
>> provided at the end. Matthew
Currently building the shim will modify shim.config in case some config
option was added or modified in the hypervisor.
Avoid that by copying shim.config to an intermediate file instead.
Signed-off-by: Juergen Gross
---
Not sure whether its worth to take that for 4.11.
In case the maintainers th
On Fri, Apr 20, 2018 at 11:42 AM, Jan Beulich wrote:
On 20.04.18 at 17:25, wrote:
>> On 20/04/18 16:20, Jason Andryuk wrote:
>>> Adding xen-devel and the Linux Xen maintainers.
>>>
>>> Summary: Some Xen users (and maybe others) are hitting a BUG in
>>> __radix_tree_lookup() under do_swap_pag
>>> On 20.04.18 at 17:42, wrote:
> On 20/04/18 16:27, Jan Beulich wrote:
> On 20.04.18 at 17:21, wrote:
>>> On 20/04/18 16:03, Jan Beulich wrote:
hvm_domain_initialise() may call this with nr being zero, which triggers
the "does not cross L3 boundary" check.
Signed-off-by:
On 20/04/18 16:52, Jason Andryuk wrote:
> On Fri, Apr 20, 2018 at 11:42 AM, Jan Beulich wrote:
> On 20.04.18 at 17:25, wrote:
>>> On 20/04/18 16:20, Jason Andryuk wrote:
Adding xen-devel and the Linux Xen maintainers.
Summary: Some Xen users (and maybe others) are hitting a BUG
>>> On 20.04.18 at 17:52, wrote:
> On Fri, Apr 20, 2018 at 11:42 AM, Jan Beulich wrote:
> On 20.04.18 at 17:25, wrote:
>>> On 20/04/18 16:20, Jason Andryuk wrote:
Adding xen-devel and the Linux Xen maintainers.
Summary: Some Xen users (and maybe others) are hitting a BUG in
>>
>>> On 20.04.18 at 17:47, wrote:
> Currently building the shim will modify shim.config in case some config
> option was added or modified in the hypervisor.
>
> Avoid that by copying shim.config to an intermediate file instead.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
flight 122350 xen-unstable-smoke running [real]
http://logs.test-lab.xenproject.org/osstest/logs/122350/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt queued
test-amd64-amd
On Fri, 20 Apr 2018, Juergen Gross wrote:
> On 20/04/18 01:00, Stefano Stabellini wrote:
> > On Thu, 19 Apr 2018, Juergen Gross wrote:
> >> On 19/04/18 10:06, Andrew Cooper wrote:
> >>> On 18/04/2018 23:15, Stefano Stabellini wrote:
> xen/arch/arm/configs/renesas.config | 80
> +
On Fri, 20 Apr 2018, Jan Beulich wrote:
> >>> On 20.04.18 at 00:43, wrote:
> > On Thu, 19 Apr 2018, Jan Beulich wrote:
> >> >>> On 19.04.18 at 00:15, wrote:
> >> > --- /dev/null
> >> > +++ b/xen/drivers/passthrough/arm/Kconfig
> >> > @@ -0,0 +1,7 @@
> >> > +
> >> > +config HAS_SMMUv2
> >> > +
flight 122351 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122351/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
test-arm64-arm64-xl-xsm 20 cap
Anthony PERARD writes ("[RFC v2 8/9] HACK libxl_exec: Check QEMU status via QMP
instead of xenstore"):
> When QEMU is restricted, the qemu on the receiving side cann't write
> anything to xenstore once the migration is started. So it cann't tell
> libxl that it is ready to continue running the gue
On 20/04/2018, 19:40, "Rich Persaud" wrote:
On Apr 20, 2018, at 13:25, Stefano Stabellini
wrote:
>
>> On Fri, 20 Apr 2018, Lars Kurth wrote:
>> ## Standardisation: virtio
>>
>> Standardization of hypervisor APIs - Matti (Open Synergy)
>>
>> Matti made a cas
In reading this and providing feedback, I'm hoping to obtain
community consensus on the following questions:
- Is there interest in this?
- Which approach is favored?
- Are there other approaches/efforts?
- Other concerns/feedback?
Executive Summary
Xen currently lacks signature verification infr
On 04/20/2018 12:02 PM, Jan Beulich wrote:
On 20.04.18 at 17:52, wrote:
>> On Fri, Apr 20, 2018 at 11:42 AM, Jan Beulich wrote:
>> On 20.04.18 at 17:25, wrote:
On 20/04/18 16:20, Jason Andryuk wrote:
> Adding xen-devel and the Linux Xen maintainers.
>
> Summary: Some Xe
On 4/17/2018 7:58 AM, Jan Beulich wrote:
On 04.04.18 at 01:01, wrote:
--- a/xen/include/asm-x86/hvm/vlapic.h
+++ b/xen/include/asm-x86/hvm/vlapic.h
@@ -137,6 +137,10 @@ void vlapic_ipi(struct vlapic *vlapic, uint32_t icr_low,
uint32_t icr_high);
int vlapic_apicv_write(struct vcpu *v, unsig
On Fri, 13 Apr 2018 11:01:49 +0100
Roger Pau Monné wrote:
>On Thu, Apr 12, 2018 at 05:50:00PM +0100, Lars Kurth wrote:
>>
>>
>> On 12/04/2018, 17:41, "Roger Pau Monne"
>> wrote:
>>
>> On Thu, Apr 12, 2018 at 05:32:57PM +0100, Lars Kurth wrote:
>>
>>
>> >may work. For me Mon,
On 20/04/18 21:20, Boris Ostrovsky wrote:
> On 04/20/2018 12:02 PM, Jan Beulich wrote:
> On 20.04.18 at 17:52, wrote:
>>> On Fri, Apr 20, 2018 at 11:42 AM, Jan Beulich wrote:
>>> On 20.04.18 at 17:25, wrote:
> On 20/04/18 16:20, Jason Andryuk wrote:
>> Adding xen-devel and the Li
94 matches
Mail list logo
