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
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,
>
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
>>> 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
Committers,
The commit moratorium is lifted.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
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
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:
> 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
>>> 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,
>> uint32_t data,
>> {
>> gdprintk(XENLOG_ERR,
>>
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
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().
>
>
>>> 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
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
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
---
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
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
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/
>>> 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 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
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,
>>> 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));
>>
>> -
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
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
> > >
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.
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()
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
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
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
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
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:
>
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
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
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
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
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
> > 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/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
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
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
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
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.
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
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
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
On 5/13/19 7:18 PM, Mathieu Tarral wrote:
> Le vendredi, mai 10, 2019 5:21 PM, Andrew Cooper
> a écrit :
>
>> On 10/05/2019 16:17, Mathieu Tarral wrote:
>>
>>> Le jeudi, mai 9, 2019 6:42 PM, Andrew Cooper andrew.coop...@citrix.com a
>>> écrit :
>>>
Therefore, the conclusion to draw is
On Mon, May 13, 2019 at 04:34:14PM +0100, Wei Liu wrote:
> 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).
Fine with me too.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things
flight 136056 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136056/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f684c3f5eef4be691e137ae64e7d00521ec201de
baseline version:
ovmf
flight 136179 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136179/
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
flight 136051 qemu-upstream-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136051/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken in
flight 136057 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136057/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken in 134594
build-arm64
>>> 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
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
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
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
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
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.
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?
--
>>> On 08.05.19 at 15:24, wrote:
> Currently x86 and ARM differ in their implementation for no good reason.
> This patch moves the ARM variant of iommu_get/set_ops() helpers into
> common code and modifies them so they deal with the __initconstrel
> ops structures used by the x86 IOMMU vendor
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 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, >page_list )
>> {
>> -
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
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/
> >
>>> 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
>>
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
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
>>> 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
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;
>>> 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
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:
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 @@
>>> 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 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
>>> 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)
>
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
Hi.
On 5/13/19 4:42 PM, Andrii Anisov wrote:
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
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.
On 13.05.19 18:45, Julien Grall wrote:
I was speaking about dd process. But Dom0 vCPUs might also be a good idea.
I see.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 13/05/2019, 08:28, "Wei Liu" wrote:
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
On 5/9/19 2:45 PM, Jan Beulich wrote:
> The two callers in common/memory.c currently call set_gpfn_from_mfn()
> themselves, so moving the call into guest_physmap_add_page() helps
> tidy their code.
>
> The two callers in common/grant_table.c fail to make that call alongside
> the one to
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
>>> 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
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
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
>>> 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
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
Am Mon, 13 May 2019 16:34:14 +0100
schrieb Wei Liu :
> Seeing that you were the last people who changed blktap2 in a meaningful
> way: do you use it at all?
The default for --enable-blktap2 in tools/configure.ac is off, and nothing
seems to pass --enable-blktap2 to configure. So I'm ok to remove
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.
>
>
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
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,
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
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 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
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 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 5/9/19 2:44 PM, Jan Beulich wrote:
> Lift its !paging_mode_translate() part into guest_physmap_add_page()
> (which is what common code calls), eliminating the dummy use of a
> (HVM-only really) P2M type in the PV case.
>
> Suggested-by: George Dunlap
> Signed-off-by: Jan Beulich
Thanks,
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
>>> 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 ?
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
> ---
>
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
1 - 100 of 114 matches
Mail list logo
