flight 136048 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136048/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf b94ab2923c2f1671b628c0210fa8ddc7abe8c617
baseline version:
xtf 1c9db326a7108203d5cfd7
branch xen-unstable
xenbranch xen-unstable
job build-arm64-xsm
testid xen-build
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: qemuu git://git.qemu.org/qemu.git
Bug introduced: 79d77bcd366190a81
On Mon, May 13, 2019 at 12:25:37AM -0600, Jan Beulich wrote:
> >>> On 10.05.19 at 18:16, wrote:
> > On 10/05/2019 17:10, Roger Pau Monne wrote:
> >> --- a/xen/arch/x86/hvm/vmsi.c
> >> +++ b/xen/arch/x86/hvm/vmsi.c
> >> @@ -688,8 +688,8 @@ static int vpci_msi_update(const struct pci_dev *pdev,
> >
> On 7. May 2019, at 15:53, Eslam Elnikety wrote:
>
> Each HVM guest currently gets a vkbd frontend/backend pair (c/s ebbd2561b4c).
> This consumes host resources unnecessarily for guests that have no use for
> vkbd. Make this behaviour tunable to allow an administrator to choose. The
> commit r
>>> On 05.03.19 at 14:28, wrote:
> The commit re-introducing it (14eb3b41d0 ["xen: reinstate previously
> unused XENMEM_remove_from_physmap hypercall"]) as well as the one having
> originally introduced it (d818f3cb7c ["hvm: Use main memory for video
> memory"]) and the one then purging it again (
Hi Julien,
Please be aware that the patch you proposed (+nocov-y += libfdt.o)
failed to build with the next error (xen 4.12):
aarch64-poky-linux-gcc -DBUILD_ID -fno-strict-aliasing -std=gnu99
-Wall -Wstrict-prototypes -Wdeclaration-after-statement
-Wno-unused-but-set-variable -Wno-unused-local-
On 5/13/19 9:18 AM, Viktor Mitin wrote:
Hi Julien,
Hi,
Please be aware that the patch you proposed (+nocov-y += libfdt.o)
failed to build with the next error (xen 4.12):
My patch is based on 4.13, although should work on Xen 4.12. But...
aarch64-poky-linux-gcc -DBUILD_ID -fno-strict-
On Wed, May 08, 2019 at 07:03:09AM -0600, Jan Beulich wrote:
> The flag being set may prevent affinity changes, as these often imply
> assignment of a new vector. When there's no possible destination left
> for the IRQ, the clearing of the flag needs to happen right from
> fixup_irqs().
>
> Additi
On Wed, May 08, 2019 at 07:07:21AM -0600, Jan Beulich wrote:
> Dynamically allocated CPU mask objects may be smaller than cpumask_t, so
> copying has to be restricted to the actual allocation size. This is
> particulary important since the function doesn't bail early when tracing
> is not active, s
>>> On 13.05.19 at 11:04, wrote:
> On Wed, May 08, 2019 at 07:03:09AM -0600, Jan Beulich wrote:
>> The flag being set may prevent affinity changes, as these often imply
>> assignment of a new vector. When there's no possible destination left
>> for the IRQ, the clearing of the flag needs to happen
flight 136041 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136041/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
test-amd64-amd64-lib
Hi Stefano,
On 5/8/19 11:47 PM, Stefano Stabellini wrote:
pfn_to_pdx expects an address, not a size, as a parameter. It expects
the end address, and the masks calculations compensate for any holes
between start and end. Pass the end address to pfn_to_pdx.
The wording is a bit difficult to rea
Hi Stefano,
On 5/8/19 11:47 PM, Stefano Stabellini wrote:
The mask calculation in pdx_init_mask is wrong when the first bank
starts at address 0x0. The reason is that pdx_init_mask will do '0 - 1'
causing an underflow. As a result, the mask becomes 0x
which is the biggest possibl
On Thu, May 09, 2019 at 05:41:27PM +0200, Vasilis Liaskovitis wrote:
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index ec71574e99..124033e5a3 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -669,6 +669,21 @@ int libxl_set_parameters(libxl_ctx *ctx, char *params)
>
Hello Julien,
On 08.05.19 16:59, Julien Grall wrote:
Hi,
On 23/04/2019 09:10, Andrii Anisov wrote:
From: Andrii Anisov
Following discussion [1] it is introduced and implemented a runstate
registration interface which uses guest's phys address instead of a virtual one.
The new hypercall emplo
osstest service owner writes ("[linux-4.9 test] 136013: regressions - FAIL"):
> flight 136013 linux-4.9 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/136013/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-ar
There seems to be some changes in Fedora 30 that cause the second boot
entry in grub.cfg to be booted instead of the first.
This means that Fedora 30 systems either always boot into an older
kernel, or in the case of systems with only one kernel installed, the
rescue image.
There also seems
> > aarch64-poky-linux-gcc -DBUILD_ID -fno-strict-aliasing -std=gnu99
> > -Wall -Wstrict-prototypes -Wdeclaration-after-statement
> > -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2
> > -fomit-frame-pointer
> > -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF
>
On 5/10/19 3:12 PM, Jan Beulich wrote:
> While it already has a CONFIG_PV wrapped around its entire body, it is
> still uselessly invoking mfn_to_gmfn(), which is about to be replaced.
> Avoid morphing this code into even more suspicious shape and remove the
> effectively dead code - translated mod
On 5/13/19 11:29 AM, Viktor Mitin wrote:
aarch64-poky-linux-gcc -DBUILD_ID -fno-strict-aliasing -std=gnu99
-Wall -Wstrict-prototypes -Wdeclaration-after-statement
-Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2
-fomit-frame-pointer
-D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERF
>>> On 13.05.19 at 12:33, wrote:
> On 5/10/19 3:12 PM, Jan Beulich wrote:
>> @@ -2640,11 +2639,11 @@ int free_page_type(struct page_info *pag
>> /* A page table is dirtied when its type count becomes zero. */
>> paging_mark_dirty(owner, page_to_mfn(page));
>>
>> -ASSERT
On 5/8/19 2:07 PM, Jan Beulich wrote:
> Dynamically allocated CPU mask objects may be smaller than cpumask_t, so
> copying has to be restricted to the actual allocation size. This is
> particulary important since the function doesn't bail early when tracing
> is not active, so even production build
On Mon, May 13, 2019 at 01:29:12PM +0300, Viktor Mitin wrote:
> > > aarch64-poky-linux-gcc -DBUILD_ID -fno-strict-aliasing -std=gnu99
> > > -Wall -Wstrict-prototypes -Wdeclaration-after-statement
> > > -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2
> > > -fomit-frame-pointer
> > >
On Tue, May 07, 2019 at 01:53:20PM +, Eslam Elnikety wrote:
> Each HVM guest currently gets a vkbd frontend/backend pair (c/s ebbd2561b4c).
> This consumes host resources unnecessarily for guests that have no use for
> vkbd. Make this behaviour tunable to allow an administrator to choose. The
>
Hi,
On 5/8/19 5:01 PM, Andrii Anisov wrote:
On 08.05.19 17:31, Julien Grall wrote:
I haven't seen them with nokpti platform so far. I am curious to know
what is your configuration here.
XEN 4.12 with our patches. Thin Dom0 is a generic armv8 Linux, LK
4.14.75 with patches from Renesas and us
flight 136050 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136050/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 133596
build-i386-prev
On 5/13/19 11:15 AM, Andrii Anisov wrote:
Hello Julien,
On 08.05.19 16:59, Julien Grall wrote:
Hi,
On 23/04/2019 09:10, Andrii Anisov wrote:
From: Andrii Anisov
Following discussion [1] it is introduced and implemented a runstate
registration interface which uses guest's phys address inst
On Wed, May 08, 2019 at 07:10:29AM -0600, Jan Beulich wrote:
> Mixed meaning was implied so far by different pieces of code -
> disagreement was in particular about whether to expect offline CPUs'
> bits to possibly be set. Switch to a mostly consistent meaning
> (exception being high priority inte
flight 136170 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136170/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
>>> On 13.05.19 at 12:42, wrote:
> On 5/8/19 2:07 PM, Jan Beulich wrote:
>> TBD: I wonder whether the function shouldn't gain an early tb_init_done
>> check, like many other trace_*() have.
>
> Yeah, avoiding these memcopies when tracing is not enabled seems like a
> good thing.
I've taken
On 08.05.19 18:40, Julien Grall wrote:
This patch is quite hard to read because you are reworking the code and at the
same time implementing the new VCPUOP. How about moving the rework in a
separate patch? The implementation can then be fold in the previous patch as
suggested by George.
OK
flight 136047 qemu-upstream-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136047/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail in 135450 REGR. vs.
133734
On Fri, May 10, 2019 at 07:28:01PM +0100, Andrew Cooper wrote:
> This is mostly to simplify future logical changes, but it does come with a
> modest redunction in compiled code size (-55, 345 => 290).
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
On 10/05/2019 19:28, Andrew Cooper wrote:
> By rearranging the logic, the timer allocation loop can reuse the common timer
> arming/clearing logic. This results in easier to follow code, and a modest
> reduction in compiled code size (-64, 290 => 226).
>
> For domains which use watchdogs, the over
On Tue, Apr 16, 2019 at 09:31:41PM +0800, Kevin Buckley wrote:
> > Oh wait, I don't think there is anything to fix there. Those sentences
> > look repetitive but they do say different things: in tools case, it says
> > "repos will be cloned"; in stubdom case, it says "external packages
> > will be
On 3/5/19 1:26 PM, Jan Beulich wrote:
> There are currently three more or less different checks:
> - _get_page_type() adjusts the IOMMU mappings according to the new type
> alone,
> - arch_iommu_populate_page_table() wants just the type to be
> PGT_writable_page,
> - iommu_hwdom_init() addition
Wei Liu (4):
gitignore: ignore .vscode directory
public/tmem.h: fix version number in comment
README: document that `python` is required
INSTALL: remove duplicate sentence
.gitignore| 1 +
INSTALL | 1 -
README| 4
xen/include/pub
The hypervisor build system requires `python`. To avoid putting too
much (confusing) information in README, mandate availability of
`python`.
Signed-off-by: Wei Liu
---
README | 4
1 file changed, 4 insertions(+)
diff --git a/README b/README
index 23e4f7c3dc..a60ccf6e9c 100644
--- a/README
The version number has been changed above due to rebasing onto 4.13
branch, but the one in the matching comment was left unchanged.
Signed-off-by: Wei Liu
---
xen/include/public/tmem.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/public/tmem.h b/xen/include/pub
The directory is created by Visual Studio Code editor to store its
local state.
Signed-off-by: Wei Liu
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 26bc583f74..3822bb75ba 100644
--- a/.gitignore
+++ b/.gitignore
@@ -30,6 +30,7 @@ cscope.out
cs
The same sentence is repeated in the next paragraph.
Signed-off-by: Wei Liu
---
INSTALL | 1 -
1 file changed, 1 deletion(-)
diff --git a/INSTALL b/INSTALL
index 9aa9ebdddc..1665ddd6a4 100644
--- a/INSTALL
+++ b/INSTALL
@@ -225,7 +225,6 @@ XEN_BUILD_TIME=hh:mm:ss
SMBIOS_REL_DATE=mm/dd/
VG
>>> On 10.05.19 at 20:28, wrote:
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -1050,6 +1050,8 @@ static void domain_watchdog_timeout(void *data)
>
> static long domain_watchdog(struct domain *d, uint32_t id, uint32_t timeout)
> {
> +long rc = 0;
I'm wondering why this
On Wed, May 08, 2019 at 07:10:59AM -0600, Jan Beulich wrote:
> All of __{assign,bind,clear}_irq_vector() manipulate struct irq_desc
> fields, and hence ought to be called with the descriptor lock held in
> addition to vector_lock. This is currently the case for only
> set_desc_affinity() (in the co
On 13/05/2019 14:47, Jan Beulich wrote:
On 10.05.19 at 20:28, wrote:
>> --- a/xen/common/schedule.c
>> +++ b/xen/common/schedule.c
>> @@ -1050,6 +1050,8 @@ static void domain_watchdog_timeout(void *data)
>>
>> static long domain_watchdog(struct domain *d, uint32_t id, uint32_t timeout)
>>
On Mon, Mar 25, 2019 at 05:00:10PM +0100, Olaf Hering wrote:
> Most pkgconfig files contain a Libs: variable, which is either /usr/lib
> or /usr/lib64. If a 32bit and a 64bit variant of xen libraries is
> installed, the last one wins. As a result compiling for the other
> bitsize will fail.
>
> In
On Tue, Apr 02, 2019 at 07:04:41AM -0600, Jan Beulich wrote:
> In x2APIC mode it is 32 bits wide.
>
> In __print_IO_APIC() drop logging of both physical and logical IDs:
> The latter covers a superset of the bits of the former in the RTE, and
> we write full 8-bit values anyway even in physical mo
During a suspend/resume, the xenwatch thread waits for all outstanding
xenstore requests and transactions to complete. This does not work
correctly for transactions started by userspace because it waits for
them to complete after freezing userspace threads which means the
transactions have no way o
On 11/27/18 12:49 PM, Razvan Cojocaru wrote:
With a sufficiently complete insn emulator, single-stepping should
not be needed at all imo. Granted we're not quite there yet with
the emulator, but we've made quite a bit of progress. As before,
if there are particular instructions you know of that t
>>> On 13.05.19 at 15:44, wrote:
> On 3/5/19 1:26 PM, Jan Beulich wrote:
>> --- a/xen/drivers/passthrough/iommu.c
>> +++ b/xen/drivers/passthrough/iommu.c
>> @@ -192,21 +192,27 @@ void __hwdom_init iommu_hwdom_init(struc
>>
>> page_list_for_each ( page, &d->page_list )
>> {
>>
On Wed, May 01, 2019 at 03:59:41PM +0100, George Dunlap wrote:
> On 4/8/19 12:09 PM, George Dunlap wrote:
> > mem-set is the primary command that users will need to use and
> > understand. Move it first, and clarify the wording; also specify that
> > you can't set the target higher than maxmem fro
>>> On 13.05.19 at 15:51, wrote:
> On 13/05/2019 14:47, Jan Beulich wrote:
> On 10.05.19 at 20:28, wrote:
>>> --- a/xen/common/schedule.c
>>> +++ b/xen/common/schedule.c
>>> @@ -1050,6 +1050,8 @@ static void domain_watchdog_timeout(void *data)
>>>
>>> static long domain_watchdog(struct dom
On Wed, May 08, 2019 at 07:11:52AM -0600, Jan Beulich wrote:
> If any particular value was to be checked against, it would need to be
> IRQ_VECTOR_UNASSIGNED.
>
> Reported-by: Roger Pau Monné
>
> Be more strict though and use valid_irq_vector() instead.
>
> Take the opportunity and also convert
>>> On 13.05.19 at 15:58, wrote:
> On 11/27/18 12:49 PM, Razvan Cojocaru wrote:
>>> With a sufficiently complete insn emulator, single-stepping should
>>> not be needed at all imo. Granted we're not quite there yet with
>>> the emulator, but we've made quite a bit of progress. As before,
>>> if th
On Mon, May 13, 2019 at 02:47:11PM +0100, Wei Liu wrote:
> The directory is created by Visual Studio Code editor to store its
> local state.
>
> Signed-off-by: Wei Liu
> ---
> .gitignore | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/.gitignore b/.gitignore
> index 26bc583f74..3822bb7
On Wed, May 08, 2019 at 07:14:06AM -0600, Jan Beulich wrote:
> Its only caller already has the IRQ descriptor in its hands, so there's
> no need for the function to re-obtain it. As a result the leading p of
> its name is no longer appropriate and hence gets dropped.
>
> Signed-off-by: Jan Beulich
Hello Julien,
On 13.05.19 14:16, Julien Grall wrote:
I am afraid I can't possible back this assumption. As I pointed out in the
previous version, I would be OK with the always map solution on Arm32 (pending
performance) because it would be possible to increase the virtual address area
by rewo
On 5/13/19 5:06 PM, Jan Beulich wrote:
On 13.05.19 at 15:58, wrote:
On 11/27/18 12:49 PM, Razvan Cojocaru wrote:
With a sufficiently complete insn emulator, single-stepping should
not be needed at all imo. Granted we're not quite there yet with
the emulator, but we've made quite a bit of progr
On Mon, May 13, 2019 at 03:13:06PM +0100, Anthony PERARD wrote:
> On Mon, May 13, 2019 at 02:47:11PM +0100, Wei Liu wrote:
> > The directory is created by Visual Studio Code editor to store its
> > local state.
> >
> > Signed-off-by: Wei Liu
> > ---
> > .gitignore | 1 +
> > 1 file changed, 1 in
Doug, ping?
On Tue, Apr 16, 2019 at 08:21:39AM +0100, Wei Liu wrote:
> We will soon provide this new capability to humans and automated
> systems.
>
> The default behaviour is retained: tip and base are passed by Gitlab
> CI.
>
> Signed-off-by: Wei Liu
> ---
> automation/gitlab-ci/build-each-c
>>> On 13.05.19 at 15:48, wrote:
> On Wed, May 08, 2019 at 07:10:59AM -0600, Jan Beulich wrote:
>> --- a/xen/drivers/passthrough/vtd/iommu.c
>> +++ b/xen/drivers/passthrough/vtd/iommu.c
>> @@ -2134,11 +2134,16 @@ static void adjust_irq_affinity(struct a
>> unsigned int node = rhsa ? pxm_to_no
>>> On 13.05.19 at 15:47, wrote:
> The version number has been changed above due to rebasing onto 4.13
> branch, but the one in the matching comment was left unchanged.
>
> Signed-off-by: Wei Liu
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
>>> On 13.05.19 at 15:47, wrote:
> --- a/README
> +++ b/README
> @@ -181,6 +181,10 @@ Various tools, such as pygrub, have the following
> runtime dependencies:
>URL:http://www.python.org/
>Debian: python
>
> +Note that the build system expects `python` to be availab
On Mon, May 13, 2019 at 02:59:30PM +0100, Wei Liu wrote:
> On Wed, May 01, 2019 at 03:59:41PM +0100, George Dunlap wrote:
> > On 4/8/19 12:09 PM, George Dunlap wrote:
> > > mem-set is the primary command that users will need to use and
> > > understand. Move it first, and clarify the wording; also
>>> On 13.05.19 at 15:47, wrote:
> --- a/INSTALL
> +++ b/INSTALL
> @@ -225,7 +225,6 @@ XEN_BUILD_TIME=hh:mm:ss
> SMBIOS_REL_DATE=mm/dd/
> VGABIOS_REL_DATE="dd Mon "
>
> -During tools build external repos will be cloned into the source tree.
> This variable can be used to point to a di
Hello Julien,
On 13.05.19 13:50, Julien Grall wrote:
Also, your DomD .config has CONFIG_UNMAP_KERNEL_AT_EL0. So how do you disable
kpti?
Sorry for the mess, I was looking for and did not find
"CONFIG_PAGE_TABLE_ISOLATION". What was googled by me as a KPTI enable config.
But it is for x86, w
On Mon, May 13, 2019 at 08:29:14AM -0600, Jan Beulich wrote:
> >>> On 13.05.19 at 15:47, wrote:
> > --- a/INSTALL
> > +++ b/INSTALL
> > @@ -225,7 +225,6 @@ XEN_BUILD_TIME=hh:mm:ss
> > SMBIOS_REL_DATE=mm/dd/
> > VGABIOS_REL_DATE="dd Mon "
> >
> > -During tools build external repos will
On 5/13/19 3:14 PM, Andrii Anisov wrote:
Hello Julien,
Hello,
On 13.05.19 14:16, Julien Grall wrote:
I am afraid I can't possible back this assumption. As I pointed out
in the previous version, I would be OK with the always map solution
on Arm32 (pending performance) because it would be p
On 3/5/19 1:28 PM, Jan Beulich wrote:
> The commit re-introducing it (14eb3b41d0 ["xen: reinstate previously
> unused XENMEM_remove_from_physmap hypercall"]) as well as the one having
> originally introduced it (d818f3cb7c ["hvm: Use main memory for video
> memory"]) and the one then purging it aga
On Mon, May 13, 2019 at 08:27:16AM -0600, Jan Beulich wrote:
> >>> On 13.05.19 at 15:47, wrote:
> > --- a/README
> > +++ b/README
> > @@ -181,6 +181,10 @@ Various tools, such as pygrub, have the following
> > runtime dependencies:
> >URL:http://www.python.org/
> >Debi
On Fri, May 10, 2019 at 05:20:47PM +0200, Olaf Hering wrote:
> If a domU has a qemu-xen instance attached, it is required to call qemus
> "xen-save-devices-state" method. Without it, the receiving side of a PV or
> PVH migration may be unable to lock the image:
>
> xen be: qdisk-51712: xen be: qdi
On 5/13/19 2:47 PM, Wei Liu wrote:
> The hypervisor build system requires `python`. To avoid putting too
> much (confusing) information in README, mandate availability of
> `python`.
>
> Signed-off-by: Wei Liu
> ---
> README | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/README b/
Hi Wei and Julien,
Thank you for the hints provided. It is appeared that it was Yocto Xen
receipt issue and not Xen coverage feature issue.
We see that xencov* tools are built anyway, even in the case when
CONFIG_COVERAGE is not enabled in hypervisor Kconfig.
Is there a reason for this?
To summar
On Mon, May 13, 2019 at 03:38:24PM +0100, George Dunlap wrote:
> On 5/13/19 2:47 PM, Wei Liu wrote:
> > The hypervisor build system requires `python`. To avoid putting too
> > much (confusing) information in README, mandate availability of
> > `python`.
> >
> > Signed-off-by: Wei Liu
> > ---
> >
On Mon, May 13, 2019 at 04:37:33PM +0200, Roger Pau Monné wrote:
> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index cb4702fd7a..7d75bd3850 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -106,6 +106,7 @@ libxl_device_model_
Hi,
On 5/13/19 3:39 PM, Viktor Mitin wrote:
Hi Wei and Julien,
---
Xen 4.13 has not been checked yet with the patch. Currently, xen 4.13
staging fails to boot due to unknown reason... it worked some days
ago.
It hangs after the next log currently:
(XEN) Failed to bring up CPU 7 (error -5)
(XEN)
What is the recommended way to disable CONFIG_PV_SHIM, which is set in
tools/firmware/Makefile? From my understanding there is no way to influence
its value from outside, which means the build always enters xen-dir/.
Olaf
pgpFnjX5_1j1z.pgp
Description: Digitale Signatur von OpenPGP
On Mon, May 13, 2019 at 08:19:04AM -0600, Jan Beulich wrote:
> >>> On 13.05.19 at 15:48, wrote:
> > On Wed, May 08, 2019 at 07:10:59AM -0600, Jan Beulich wrote:
> >> --- a/xen/drivers/passthrough/vtd/iommu.c
> >> +++ b/xen/drivers/passthrough/vtd/iommu.c
> >> @@ -2134,11 +2134,16 @@ static void ad
Am Mon, 13 May 2019 16:37:33 +0200
schrieb Roger Pau Monné :
> FTR I would have preferred a pre-patch that did the move of this chunk
> of code into libxl__domain_set_device_model without any functional
> change, and then a second patch that introduces the new functionality.
If that needs to be d
On Mon, May 13, 2019 at 05:39:55PM +0300, Viktor Mitin wrote:
> Hi Wei and Julien,
>
> Thank you for the hints provided. It is appeared that it was Yocto Xen
> receipt issue and not Xen coverage feature issue.
> We see that xencov* tools are built anyway, even in the case when
> CONFIG_COVERAGE is
On Mon, May 13, 2019 at 04:45:21PM +0200, Olaf Hering wrote:
> Am Mon, 13 May 2019 16:37:33 +0200
> schrieb Roger Pau Monné :
>
> > FTR I would have preferred a pre-patch that did the move of this chunk
> > of code into libxl__domain_set_device_model without any functional
> > change, and then a s
>>> On 10.05.19 at 20:28, wrote:
> All modifications to the watchdog_inuse_map happen with d->watchdog_lock held,
> so there are no concurrency problems to deal with.
But concurrency problems can also occur for readers. While
not a problem afaict, dump_domains() actually has such an
example (and
>>> On 13.05.19 at 16:45, wrote:
> On Mon, May 13, 2019 at 08:19:04AM -0600, Jan Beulich wrote:
>> >>> On 13.05.19 at 15:48, wrote:
>> > On Wed, May 08, 2019 at 07:10:59AM -0600, Jan Beulich wrote:
>> >> --- a/xen/drivers/passthrough/vtd/iommu.c
>> >> +++ b/xen/drivers/passthrough/vtd/iommu.c
>>
On Mon, May 13, 2019 at 04:53:21PM +0200, Olaf Hering wrote:
> What is the recommended way to disable CONFIG_PV_SHIM, which is set in
> tools/firmware/Makefile? From my understanding there is no way to influence
> its value from outside, which means the build always enters xen-dir/.
>
There isn't
>>> On 13.05.19 at 16:35, wrote:
> On 3/5/19 1:28 PM, Jan Beulich wrote:
>> The commit re-introducing it (14eb3b41d0 ["xen: reinstate previously
>> unused XENMEM_remove_from_physmap hypercall"]) as well as the one having
>> originally introduced it (d818f3cb7c ["hvm: Use main memory for video
>> m
On 13/05/2019 16:01, Jan Beulich wrote:
On 10.05.19 at 20:28, wrote:
>> All modifications to the watchdog_inuse_map happen with d->watchdog_lock
>> held,
>> so there are no concurrency problems to deal with.
> But concurrency problems can also occur for readers. While
> not a problem afaict,
On Mon, May 13, 2019 at 04:53:21PM +0200, Olaf Hering wrote:
> What is the recommended way to disable CONFIG_PV_SHIM, which is set in
> tools/firmware/Makefile? From my understanding there is no way to influence
> its value from outside, which means the build always enters xen-dir/.
I think the fo
>>> On 13.05.19 at 13:32, wrote:
> On Wed, May 08, 2019 at 07:10:29AM -0600, Jan Beulich wrote:
>> --- a/xen/arch/x86/io_apic.c
>> +++ b/xen/arch/x86/io_apic.c
>> @@ -680,7 +680,7 @@ void /*__init*/ setup_ioapic_dest(void)
>> continue;
>> irq = pin_2_irq(irq_entry, io
>>> On 08.05.19 at 15:23, wrote:
> An 'if ( !iommu_enabled )' followed by an 'if ( iommu_enabled )' with
> only a printk() in between seems a little silly. Move the printk() and
> use 'else' instead.
>
> Signed-off-by: Paul Durrant
Acked-by: Jan Beulich
_
On 5/10/19 7:28 PM, Andrew Cooper wrote:
> This is mostly to simplify future logical changes, but it does come with a
> modest redunction in compiled code size (-55, 345 => 290).
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: George Dunlap
On Mon, May 13, 2019 at 05:20:05PM +0200, Roger Pau Monné wrote:
> On Mon, May 13, 2019 at 04:53:21PM +0200, Olaf Hering wrote:
> > What is the recommended way to disable CONFIG_PV_SHIM, which is set in
> > tools/firmware/Makefile? From my understanding there is no way to influence
> > its value fr
On 13.05.19 17:34, Julien Grall wrote:
My point of my message is to understand the exact workload/setup you are using.
"dd" was not an entirely obvious choice for CPUBurn and Google didn't provide a
lot of website backing this information.
Anyway, now I understand a bit more the workload,
Hi,
On 5/13/19 4:29 PM, Andrii Anisov wrote:
On 13.05.19 17:34, Julien Grall wrote:
My point of my message is to understand the exact workload/setup you
are using. "dd" was not an entirely obvious choice for CPUBurn and
Google didn't provide a lot of website backing this information.
Anywa
Hello
Seeing that you were the last people who changed blktap2 in a meaningful
way: do you use it at all?
I'm thinking about dropping it (again).
(Obv. the wider community is welcome to voice their opinion as well.)
Wei.
___
Xen-devel mailing list
X
flight 136178 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136178/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
>>> On 08.05.19 at 15:24, wrote:
> It's not vendor specific so it shouldn't really be there.
Perhaps, but this needs better justification:
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2372,10 +2372,6 @@ static int __init vtd_setup(void)
> P(i
On 13.05.19 18:31, Julien Grall wrote:
So, are you running 4 dd (one for each core) in parallel? Are they pinned?
Yes, sure I run 4 dd's in parallel to get all VCPUs loaded. No they are not
pinned.
--
Sincerely,
Andrii Anisov.
___
Xen-devel maili
>>> On 13.05.19 at 17:17, wrote:
> On 13/05/2019 16:01, Jan Beulich wrote:
> On 10.05.19 at 20:28, wrote:
>>> All modifications to the watchdog_inuse_map happen with d->watchdog_lock
>>> held,
>>> so there are no concurrency problems to deal with.
>> But concurrency problems can also occur f
On 5/13/19 4:38 PM, Andrii Anisov wrote:
On 13.05.19 18:31, Julien Grall wrote:
So, are you running 4 dd (one for each core) in parallel? Are they
pinned?
Yes, sure I run 4 dd's in parallel to get all VCPUs loaded. No they are
not pinned.
From my understanding, if you want consistency,
On 13.05.19 18:40, Julien Grall wrote:
From my understanding, if you want consistency, then setting the affinity will
definitely help. Otherwise, you may have the scheduler to kick up and also
balancing.
Sorry, do you mean setting affinity for dd processes, or Dom0 VCPUs, or both?
--
Sincer
On 13/05/2019 17:34, Wei Liu wrote:
> Hello
>
> Seeing that you were the last people who changed blktap2 in a meaningful
> way: do you use it at all?
Not me. I was only changing it to comply with the rest of the build
(adding pkg-config file).
I SUSE builds (SLE, openSUSE) it is not configured.
1 - 100 of 116 matches
Mail list logo
