flight 123480 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123480/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 16 guest-start/debian.repeat fail REGR. vs. 123222
flight 123473 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123473/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-migrupgrade 10 xen-boot/src_hostfail REGR. vs. 123122
flight 74770 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74770/
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 like
74743
baseline version:
On Fri, 1 Jun 2018, Julien Grall wrote:
> Hi,
> Sorry for the formatting. I am pretty sure you need to CC "THE REST" here.
>
> On Thu, 31 May 2018, 22:50 Stefano Stabellini, wrote:
> Add specific per-platform defaults for NR_CPUS. Note that the order of
> the defaults matter: they
On Fri, 1 Jun 2018, Jan Beulich wrote:
> >>> On 31.05.18 at 23:48, wrote:
> > Add specific per-platform defaults for NR_CPUS. Note that the order of
> > the defaults matter: they need to go first, otherwise the generic
> > defaults will be applied.
>
> Still I'd prefer the ARM ones to follow the
On Fri, 1 Jun 2018, Julien Grall wrote:
> Hi,
> Sorry for the formatting.
>
> On Thu, 31 May 2018, 22:50 Stefano Stabellini, wrote:
> Add a tiny kconfig configuration. Enabled NULL and Credit schedulers.
> Support only 8 cpus. It only carries non-default options (use make
>
On Fri, 1 Jun 2018, Julien Grall wrote:
> Hi Stefano,
> Sorry for formatting.
>
> On Thu, 31 May 2018, 22:50 Stefano Stabellini, wrote:
> Add a "Platform Support" menu with three umbrella kconfig options: QEMU,
> RCAR3 and MPSOC. They enable the required options for their hardware
>
flight 123449 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123449/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123367
test-armhf-armhf-libvirt 14
On 5/31/18 4:48 PM, Stefano Stabellini wrote:
> One note about Kconfig renaming: I can see the benefit of being
> consistent with the naming and using HAS_ only for options that are
> always enabled, but I really don't have a strong opinion on this topic.
So fwiw, the HAS_ fields come from the
On 5/29/18 5:28 AM, Ian Jackson wrote:
> Doug Goldstein writes ("Re: [Xen-devel] XSM in osstest, grub config,
> outstanding patch"):
>> So I believe the path forward here was that we'd bake the "default" XSM
>> policy into Xen and the user could then override it by supplying one
>> with the
On 5/31/2018 11:16 PM, Manish Jaggi wrote:
>
>
> On 05/31/2018 09:27 PM, Sameer Goel wrote:
>>
>> On 5/30/2018 10:13 PM, Manish Jaggi wrote:
>>>
>>> On 05/31/2018 04:31 AM, Sameer Goel wrote:
+
+static int arm_smmu_iommu_domain_init(struct domain *d)
>>> Where is
On 31/05/18 15:05, Marcello Seri wrote:
> When xenstore was updated to support safe-string, some unnecessary
> copies were introduced. A further patch reduced the copies at the price
> of many calls to unsafe conversions between bytes and strings. In the
> port we also did not notice that some C
On 01/06/18 16:06, Andrew Cooper wrote:
> c/s "x86/pv: Introduce and use x86emul_write_dr()" fixed a bug with IO shadow
> handling, in that it remained stale and visible until %dr7.L/G got set again.
>
> However, it neglected the -EPERM return inbetween these two hunks, introducing
> a different
flight 123456 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123456/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 123391
test-armhf-armhf-libvirt 14
flight 123447 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123447/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 13 migrate-support-checkfail never pass
test-amd64-i386-xl-pvshim12
The xen pci_assign_dev_load_option_rom() currently creates a RAM
memory region with memory_region_init_ram_nomigrate(), and then
manually registers it with vmstate_register_ram(). In fact for
its only callsite, the 'owner' pointer we use for the init call
and the '>qdev' pointer we use for the
flight 123442 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123442/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 fail
in 123379 pass in 123442
On Thu, 31 May 2018 23:30:35 -0600
"Jan Beulich" wrote:
Alexey G 05/31/18 7:15 AM >>>
>>On Wed, 30 May 2018 02:12:37 -0600 "Jan Beulich" wrote:
>> On 29.05.18 at 20:47, wrote:
On Wed, 30 May 2018 03:56:07 +1000
Alexey G wrote:
>On Tue, 29 May 2018 08:23:51
On Fri, Jun 1, 2018 at 8:40 AM Boris Ostrovsky
wrote:
>
> On 05/29/2018 06:15 PM, Thomas Garnier wrote:
> > diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S
> > index ca2d3b2bf2af..82ba89ba8bb3 100644
> > --- a/arch/x86/xen/xen-pvh.S
> > +++ b/arch/x86/xen/xen-pvh.S
> > @@ -114,8
>>> On 01.06.18 at 17:28, wrote:
> On Fri, 1 Jun 2018, Jan Beulich wrote:
>> >>> On 31.05.18 at 23:48, wrote:
>> > @@ -54,6 +54,7 @@ config HAS_SCIF
>> >
>> > config HAS_EHCI
>> >bool
>> > + depends on X86
>>
>> Just FTR: I won't NAK this, but I also won't ACK it.
>
> Just this one
On 05/29/2018 06:15 PM, Thomas Garnier wrote:
> diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S
> index ca2d3b2bf2af..82ba89ba8bb3 100644
> --- a/arch/x86/xen/xen-pvh.S
> +++ b/arch/x86/xen/xen-pvh.S
> @@ -114,8 +114,8 @@ ENTRY(pvh_start_xen)
> call xen_prepare_pvh
>
>
On Fri, 1 Jun 2018, Jan Beulich wrote:
> >>> On 31.05.18 at 23:48, wrote:
> > @@ -54,6 +54,7 @@ config HAS_SCIF
> >
> > config HAS_EHCI
> > bool
> > + depends on X86
>
> Just FTR: I won't NAK this, but I also won't ACK it.
Just this one line change, right? You would be fine with acking
On Fri, 1 Jun 2018, Jan Beulich wrote:
> >>> On 31.05.18 at 23:48, wrote:
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -20,8 +20,16 @@ config HAS_DEVICE_TREE
> > config HAS_EX_TABLE
> > bool
> >
> > -config HAS_MEM_ACCESS
> > - bool
> > +config MEM_ACCESS_ALWAYS_ON
>
This will handle messages received, and call callbacks registered via
libxl__ev_qmp_register().
This also print error messages from QMP on behalf of the callback.
Signed-off-by: Anthony PERARD
---
Should we let callbacks print error messages themself? They already have
the error class, which
Allow to generate a JSON string from a libxl__json_object,
usefull for debugging.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_internal.h | 3 +++
tools/libxl/libxl_json.c | 36
2 files changed, 39 insertions(+)
diff --git
This new function qmp_prepare_qmp_cmd() can be reuse later when
introducing a different way to communicate with a QMP server,
libxl__ev_qmp.
Also, add the QMP end of command '\r\n' into the generated string.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 60
This set of function allow to parse a JSON string that is spread accross
different memory location.
This is usefull when a JSON string is received from a remote process,
and in order to avoid using realloc, the message is recorded in multiple
buffers.
Signed-off-by: Anthony PERARD
---
This is a first patch to implement libxl__ev_qmp, it only connect to the
QMP socket of QEMU and register a callback that does nothing.
Callback functions will be implemented in following patches.
Signed-off-by: Anthony PERARD
---
TODO:
This would probably needs to have a list in CTX, with state
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 4da84dcf16..1184ca823f 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -111,8 +111,6 @@ struct
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_internal.h | 2 +-
tools/libxl/libxl_json.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c582894589..12bbfe4a63 100644
---
First step into taking care of the input from QEMU's QMP socket. For
now, we read data and store them in buffers.
Parsing of the data will be done in the following patches.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 113
1 file changed,
This is to prepare libxl_cdrom_insert to be able to send commands to
QEMU via the libxl__ev_qmp. The next patch is going to make use of it.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_disk.c | 195 +++
1 file changed, 138 insertions(+), 57
The libxl__ev_qmp_* will now send commands to QEMU when the socket is
ready for writes. Also stop pulling for POLLOUT events once the send
queue is empty.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 48 +
1 file changed, 48 insertions(+)
That buffer is only used locally, and never reuse accross different call
of qmp_next. So remove it form the handler.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/libxl_qmp.c
Calling libxl__ev_qmp_register() will prepare a command to be sent to
QEMU and stash it in a queue to be sent later.
The actual sent will be done in a separate patch.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_internal.h | 39 +++-
tools/libxl/libxl_qmp.c |
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 98 +
1 file changed, 98 insertions(+)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 48dc376307..e4441f76f4 100644
--- a/tools/libxl/libxl_qmp.c
+++
This function is a reimplementation of libxl__qmp_insert_cdrom() but to be
use with libxl__ev_qmp.
It also open the cdrom in libxl and send the FD via QMP, so QEMU doesn't
need access permition on the cdrom file.
libxl_cdrom_insert() will need to be reorganize to be able to use that
new
When starting QEMU with dm_restrict=1, pre-open the QMP socket before
exec QEMU. That socket will be usefull to findout if QEMU is ready, and
pre-opening it means that libxl can connect to it without waiting for
QEMU to create it.
The pre-openning is conditionnal, based on the use of dm_restrict
This is only activated when dm_restrict=1, as explained in the previous
patch "libxl_dm: Pre-open QMP socket for QEMU"
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_dm.c | 7 ++
tools/libxl/libxl_exec.c | 44
tools/libxl/libxl_internal.h
So when QEMU is involve, the operation will be asynchrone and will
finish later.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_disk.c | 55 +++-
1 file changed, 49 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/libxl_disk.c
Remove the libxl__qmp_handler* argument so the function can be reused
later in a different context.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index
Slight change in the infrastructure to allow to send a buffer before any
command that would already been prepared.
qmp_capabilities needs to be the first command sent.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 87 ++---
1 file changed, 82
On Fri, Jun 01, 2018 at 03:36:49PM +0100, Anthony PERARD wrote:
> The real meat in this patch series start with patch
> "libxl_qmp_ev: Introduce libxl__ev_qmp_start() to connect to QMP"
> which implement libxl__ev_qmp_* functions to turn the QMP client into
> asynchronous mode.
>
> This comes
In case QEMU have restricted access to the system, open the file for it,
and QEMU will save its state to this file descritor.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 38 +-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git
The real meat in this patch series start with patch
"libxl_qmp_ev: Introduce libxl__ev_qmp_start() to connect to QMP"
which implement libxl__ev_qmp_* functions to turn the QMP client into
asynchronous mode.
This comes with two examples on how to use it:
* "libxl_disk: Have libxl_cdrom_insert use
This patch fix complilation error with #define DEBUG_RECEIVED of the
macro DEBUG_REPORT_RECEIVED.
error: field precision specifier ‘.*’ expects argument of type ‘int’, but
argument 9 has type ‘ssize_t {aka long int}’
Signed-off-by: Anthony PERARD
Acked-by: Wei Liu
---
Notes:
New in RFC
The libxl__log() call was missing the domid.
The macro DBG is using LIBXL__LOG which rely on a "gc". Add a GC where
needed.
Signed-off-by: Anthony PERARD
Reviewed-by: Wei Liu
---
Notes:
v3:
- Add a commit message.
New in RFC v2
tools/libxl/libxl_event.c | 8 +++-
1 file
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_json.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 0823b8cfd2..dc93a88ef1 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -59,8 +59,8
This variable is only used once, no need to keep it in the handler.
Also fix coding style (remove space after sizeof).
And allow strncpy to use all the space in sun_path.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 14 ++
1 file changed, 6 insertions(+), 8
Signed-off-by: Anthony PERARD
Acked-by: Wei Liu
---
Notes:
v3:
- Add documentation of the qmp_callback_t type.
New in RFC v2
tools/libxl/libxl_qmp.c | 42 +
1 file changed, 42 insertions(+)
diff --git a/tools/libxl/libxl_qmp.c
In qmp_next(), the inner loop should only try to parse messages from
QMP, if there is more than one.
The handling of the receive buffer ('incomplete'), should be done at the
same scope level as read(). It doesn't need to be handle more that once
after a read.
Before this patch, when on message
Adding the ability to send a file descriptor from libxl to QEMU via the
QMP interface. This will be use with the "add-fd" QMP command.
Signed-off-by: Anthony PERARD
Acked-by: Wei Liu
---
tools/libxl/libxl_qmp.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff
On 01/06/18 15:06, Andrew Cooper wrote:
> c/s "x86/pv: Introduce and use x86emul_write_dr()" fixed a bug with IO shadow
> handling, in that it remained stale and visible until %dr7.L/G got set again.
>
> However, it neglected the -EPERM return inbetween these two hunks, introducing
> a different
c/s "x86/pv: Introduce and use x86emul_write_dr()" fixed a bug with IO shadow
handling, in that it remained stale and visible until %dr7.L/G got set again.
However, it neglected the -EPERM return inbetween these two hunks, introducing
a different bug in which a write to %dr7 which tries to set IO
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
In existing code the virtual 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
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 read
only as a
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
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. With this
When a CPU is hot-unplugged we need to disable timers and release
their interrupts in order to free the memory that was allocated when
interrupts were requested (using request_irq()). The request_irq()
is called for each timer interrupt when the CPU gets hotplugged
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
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
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 when the CPU dies. The call to
remove_cpu_sibling_map() is made from a notifier callback when
CPU_DEAD event is received.
On boot, enabling errata workarounds will be triggered by the boot CPU
from start_xen(). On CPU hotplug (non-boot scenario) this would not be
done. This patch adds the code required to enable errata workarounds for
a CPU being hotplugged after the system boots. This is triggered using
a notifier.
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 run is configured for baseline tests only.
flight 74768 xen-4.10-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74768/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 15
flight 123438 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123438/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumprun6 rumprun-buildfail REGR. vs. 123370
On 31 May 2018 at 20:08, Stefano Stabellini wrote:
> The following changes since commit c181ddaa176856b3cd2dfd12bbcf25fa9c884a97:
>
> Merge remote-tracking branch
> 'remotes/pmaydell/tags/pull-target-arm-20180531-1' into staging (2018-05-31
> 17:00:55 +0100)
>
> are available in the git
Boris, I dropped your r-b for this patch as I changed
EXPORT_SYMBOL to EXPORT_SYMBOL_GPL as Juergen requested
On 06/01/2018 02:41 PM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Make set/clear page private code shared and accessible to
other kernel modules which can re-use
From: Oleksandr Andrushchenko
1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
as a DMA write-combine/coherent buffer, e.g. allocated with
From: Oleksandr Andrushchenko
Only gnttab_{alloc|free}_pages are exported as EXPORT_SYMBOL
while all the rest are exported as EXPORT_SYMBOL_GPL, thus
effectively making it not possible for non-GPL driver modules
to use grant table module. Export gnttab_{alloc|free}_pages as
EXPORT_SYMBOL_GPL so
From: Oleksandr Andrushchenko
Allow mappings for DMA backed buffers if grant table module
supports such: this extends grant device to not only map buffers
made of balloon pages, but also from buffers allocated with
dma_alloc_xxx.
Signed-off-by: Oleksandr Andrushchenko
---
From: Oleksandr Andrushchenko
Make set/clear page private code shared and accessible to
other kernel modules which can re-use these instead of open-coding.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/grant-table.c | 54 +--
From: Oleksandr Andrushchenko
This work is in response to my previous attempt to introduce Xen/DRM
zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
frontends/backends. There is also an existing hyper_dmabuf approach
available [3] which, if reworked to utilize the proposed
From: Oleksandr Andrushchenko
1. Import a dma-buf with the file descriptor provided and export
granted references to the pages of that dma-buf into the array
of grant references.
2. Add API to close all references to an imported buffer, so it can be
released by the owner. This is only
From: Oleksandr Andrushchenko
Allow creating grant device context for use by kernel modules which
require functionality, provided by gntdev. Export symbols for dma-buf
API provided by the module.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev-dmabuf.c | 6 +++
From: Oleksandr Andrushchenko
Memory {increase|decrease}_reservation and VA mappings update/reset
code used in balloon driver can be made common, so other drivers can
also re-use the same functionality without open-coding.
Create a dedicated file for the shared code and export corresponding
From: Oleksandr Andrushchenko
Add UAPI and IOCTLs for dma-buf grant device driver extension:
the extension allows userspace processes and kernel modules to
use Xen backed dma-buf implementation. With this extension grant
references to the pages of an imported dma-buf can be exported
for other
From: Oleksandr Andrushchenko
Extend grant table module API to allow allocating buffers that can
be used for DMA operations and mapping foreign grant references
on top of those.
The resulting buffer is similar to the one allocated by the balloon
driver in terms that proper memory reservation is
Hi Stefano,
On 01.06.18 00:48, Stefano Stabellini wrote:
Add a "Platform Support" menu with three umbrella kconfig options: QEMU,
RCAR3 and MPSOC. They enable the required options for their hardware
platform.
In the case of the MPSOC that has a platform file under
arch/arm/platforms/, build
>>> On 31.05.18 at 23:48, wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -20,8 +20,16 @@ config HAS_DEVICE_TREE
> config HAS_EX_TABLE
> bool
>
> -config HAS_MEM_ACCESS
> - bool
> +config MEM_ACCESS_ALWAYS_ON
> + def_bool n
Only "bool" please - there should be
>>> On 31.05.18 at 23:48, wrote:
> Add specific per-platform defaults for NR_CPUS. Note that the order of
> the defaults matter: they need to go first, otherwise the generic
> defaults will be applied.
Still I'd prefer the ARM ones to follow the X86 one (keeping the ARM ones
together), unless
>>> On 31.05.18 at 23:48, wrote:
> Add a Xen build target to count the lines of code of the source files
> built. Uses `cloc' to do the job.
>
> With Xen on ARM taking off in embedded, IoT, and automotive, we are
> seeing more and more uses of Xen in constrained environments. Users and
> system
>>> On 31.05.18 at 23:48, wrote:
> @@ -54,6 +54,7 @@ config HAS_SCIF
>
> config HAS_EHCI
> bool
> + depends on X86
Just FTR: I won't NAK this, but I also won't ACK it.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
>>> On 30.05.18 at 19:34, wrote:
> @@ -117,6 +115,9 @@ integer_param("debug_stack_lines", debug_stack_lines);
> static bool opt_ler;
> boolean_param("ler", opt_ler);
>
> +/* LastExceptionFromIP on this hardware. Zero if LER is not in use. */
> +uint32_t __read_mostly ler_msr;
Hmm, this is
branch xen-4.9-testing
xenbranch xen-4.9-testing
job test-amd64-amd64-xl-qemut-ws16-amd64
testid xen-boot
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu
On 01/06/18 10:10, Jan Beulich wrote:
On 31.05.18 at 11:14, wrote:
>> On 31/05/18 10:32, Juergen Gross wrote:
>>> On 31/05/18 08:00, osstest service owner wrote:
flight 123379 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123379/
Regressions
>>> On 01.06.18 at 06:43, wrote:
> flight 123408 xen-4.6-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/123408/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-xsm 7 xen-boot
>>> On 30.05.18 at 22:24, wrote:
> On Tue, 29 May 2018, Jan Beulich wrote:
>> Also - do we perhaps want the
>> prompt to additionally have an EXPERT dependency? Without you saying why
>> you want this configurable I can't tell whether this would make sense.
>
> I am doing this mostly to reduce
>>> On 31.05.18 at 11:14, wrote:
> On 31/05/18 10:32, Juergen Gross wrote:
>> On 31/05/18 08:00, osstest service owner wrote:
>>> flight 123379 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/123379/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and
>>> On 31.05.18 at 18:03, wrote:
> This is essentially a "take 2" of c/s 82540b66ce "x86/VT-x: Fix determination
> of EFER.LMA in vmcs_dump_vcpu()" because in hindight, that change was more
> problematic than useful.
>
> The original reason was to fix the logic for determining when not to print
>>> On 31.05.18 at 11:10, wrote:
> Hi,
>
> On 31/05/18 00:29, Kang, Luwei wrote:
>>> -Original Message-
>>> From: Julien Grall [mailto:julien.gr...@arm.com]
>>> Sent: Wednesday, May 30, 2018 11:15 PM
>>> To: Kang, Luwei ; xen-de...@lists.xen.org
>>> Cc: andrew.coop...@citrix.com;
92 matches
Mail list logo
