On 16/05/2019 16:41, Jan Beulich wrote:
On 16.05.19 at 15:51, wrote:
>> On 16/05/2019 15:05, Jan Beulich wrote:
>> On 06.05.19 at 08:56, wrote:
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -154,6 +154,24 @@ static void idle_loop(void)
}
}
On Thu, May 16, 2019 at 3:31 AM Jan Beulich wrote:
>
> >>> On 16.05.19 at 02:02, wrote:
> > Signed-off-by: Alistair Francis
>
> At least to me it is far from obvious why we would want/need to
> do this update, or where the canonical "latest version" lives and
> hence where this is coming from.
On Thu, May 16, 2019 at 3:32 AM Jan Beulich wrote:
>
> >>> On 16.05.19 at 02:02, wrote:
> > Make the asm/vpl011.h dependent on the ARM architecture.
>
> But we only have x86 and Arm right now. A word more about
> your motivation would help.
As the code currently is no one can add another
On Thu, May 16, 2019 at 6:30 AM Wei Liu wrote:
>
> On Thu, May 16, 2019 at 03:18:19PM +0200, Olaf Hering wrote:
> > Am Thu, 16 May 2019 12:39:02 +0100
> > schrieb Wei Liu :
> >
> > > autotools shipped in all the distros we care about
> >
> > I see autoconf 2.69 is available practically
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-credit1
testid guest-saverestore
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf
flight 136248 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136248/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 130965
flight 136233 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136233/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 135805
test-amd64-amd64-libvirt 13
Hi Andrew & Jan,
On 5/16/19 8:58 AM, Jan Beulich wrote:
On 15.05.19 at 22:12, wrote:
On 15/05/2019 20:58, Julien Grall wrote:
Hi all,
It looks like the structures vcpu_guest_core_regs and
vcpu_guest_context does not correctly reflect the AArch64 state. For
instance, all Arm64 system
Disable it by default as it is only an experimental subsystem.
Signed-off-by: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau Monne
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: George
Hi Anthony,
Thank you for CCing me.
On 5/16/19 11:37 AM, Anthony PERARD wrote:
On Wed, May 15, 2019 at 07:48:17PM +, osstest service owner wrote:
flight 136184 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136184/
Regressions :-(
Tests which did
Improves performance for release builds.
Signed-off-by: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau Monne
---
xen/include/asm-x86/mem_sharing.h | 4
1 file changed, 4 insertions(+)
diff --git a/xen/include/asm-x86/mem_sharing.h
Patch cf4b30dca0a "Add debug code to detect illegal page_lock and put_page_type
ordering" added extra sanity checking to page_lock/page_unlock for debug builds
with the assumption that no hypervisor path ever locks two pages at once.
This assumption doesn't hold during memory sharing so we copy a
Calling _put_page_type while also holding the page_lock
for that page can cause a deadlock.
The comment being dropped is incorrect since it's now out-of-date.
Signed-off-by: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Wei Liu
Cc: Roger Pau Monne
---
This series
flight 136246 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136246/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 127792
build-amd64
flight 136387 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136387/
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 136232 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136232/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-saverestore.2 fail REGR. vs.
135813
Tests
flight 136220 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136220/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-pvgrub 7 xen-bootfail REGR. vs. 128858
flight 136231 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136231/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 26 leak-check/check/src_host fail REGR. vs.
135683
On 16.05.19 10:41, Sironi, Filippo wrote:
>> On 16. May 2019, at 18:40, Boris Ostrovsky
>> wrote:
>>
>> On 5/16/19 11:33 AM, Alexander Graf wrote:
>>> On 16.05.19 08:25, Sironi, Filippo wrote:
> On 16. May 2019, at 15:56, Graf, Alexander wrote:
>
> On 14.05.19 08:16, Filippo Sironi
> On 16. May 2019, at 18:40, Boris Ostrovsky wrote:
>
> On 5/16/19 11:33 AM, Alexander Graf wrote:
>> On 16.05.19 08:25, Sironi, Filippo wrote:
On 16. May 2019, at 15:56, Graf, Alexander wrote:
On 14.05.19 08:16, Filippo Sironi wrote:
> On x86, we report the UUID in DMI
Hi Viktor,
Thank you for the quick respin. I have some comments below regarding the commit
message and process.
On 16/05/2019 14:20, Viktor Mitin wrote:
The patch resolves 'xencov' crashes in case of Aarch64.
All the .init.* sections are stripped after boot,
it means that anything in
On 16.05.19 18:44, Julien Grall wrote:
Hi,
Hi, Julien
That's correct. If I don't hear anything by Monday, I will merge the
two patches.
I haven't heard anything from Stefano. I have now merged the two
remaining patches.
Great, thank you! Now, I hope we can say that Renesas Stout
On 16/05/2019 17:17, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
>> In addition,
> Thanks.
>
> wanting discussion:
>
>> 365aabb6e502 "tools/libxendevicemodel: add
>> xendevicemodel_modified_memory_bulk to map" is possibly a candidate, but
>> is
On 01.05.19 00:02, Stefano Stabellini wrote:
Hi all,
Hi, Stefano
This series introduces a memory policy parameter for the iomem option,
so that we can map an iomem region into a guest as cacheable memory.
Then, this series fixes the way Xen handles reserved memory regions on
ARM: they
On 5/16/19 11:33 AM, Alexander Graf wrote:
> On 16.05.19 08:25, Sironi, Filippo wrote:
>>> On 16. May 2019, at 15:56, Graf, Alexander wrote:
>>>
>>> On 14.05.19 08:16, Filippo Sironi wrote:
On x86, we report the UUID in DMI System Information (i.e., DMI Type 1)
as VM UUID.
Jan Beulich writes ("Re: [Xen-devel] preparations for 4.11.2"):
> Unless these are really urgent to put in, I'd like them to be deferred
> to 4.11.3. With XSA-297 out we've already started the (leaf tree)
> tagging process, so I was really hoping to get this much delayed
> release out rather
Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> In addition,
Thanks.
wanting discussion:
> 365aabb6e502 "tools/libxendevicemodel: add
> xendevicemodel_modified_memory_bulk to map" is possibly a candidate, but
> is also complicated by the stable SONAME. It is
Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> Oh, and 677e64dbe315343620c3b266e9eb16623b118038 "tools/ocaml: Dup2
> /dev/null to stdin in daemonize()" again for 4.12 and earlier.
This is already in 4.12. It's quite alarming so I decided to backport
it all the way to 4.7
>>> On 16.05.19 at 17:46, wrote:
> On some machines (for example Thinkpad P52), UEFI GOP reports
> framebuffer located above 4GB (0x40 on that machine). This
> address does not fit in {xen,dom0}_vga_console_info.u.vesa_lfb.lfb_base
> field, which is 32bit. The overflow here cause all kind
flight 136374 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136374/
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
Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> ffb60a58df48419c1f2607cd3cc919fa2bfc9c2d "tools/misc/xenpm: fix getting
> info when some CPUs are offline" for 4.11 and earlier.
Thanks, queued for 4.11 and 4.10.
Ian.
___
Xen-devel
On 16/05/2019, 04:47, "Jan Beulich" wrote:
>>> On 16.05.19 at 00:18, wrote:
> +# Mappings to track files are of the following format
> +# ---
> +# manual|auto xen-file name-of-original-repo original-file commit-id
> +#
>
Hi,
On 08/05/2019 12:25, Dario Faggioli wrote:
On Wed, 2019-05-08 at 12:59 +0300, Andrii Anisov wrote:
From: Andrii Anisov
ARM's schedule_tail() is called from two places: context_switch() and
continue_new_vcpu(). Both functions are always called with
prev!=current. So replace the
On some machines (for example Thinkpad P52), UEFI GOP reports
framebuffer located above 4GB (0x40 on that machine). This
address does not fit in {xen,dom0}_vga_console_info.u.vesa_lfb.lfb_base
field, which is 32bit. The overflow here cause all kind of memory
corruption when anything tries
On Thu, May 16, 2019 at 08:59:36AM -0600, Jan Beulich wrote:
> >>> On 16.05.19 at 16:07, wrote:
> > --- a/xen/drivers/video/vesa.c
> > +++ b/xen/drivers/video/vesa.c
> > @@ -40,6 +40,11 @@ static int __init parse_font_height(const char *s)
> > }
> > custom_param("font", parse_font_height);
> >
Hi,
On 08/05/2019 17:34, Julien Grall wrote:
On 08/05/2019 17:30, Oleksandr wrote:
On 08.05.19 19:19, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 02/05/2019 18:00, Oleksandr Tyshchenko wrote:
Oleksandr Tyshchenko (4):
xen/arm: drivers: scif: Extend driver to handle other
On 16.05.19 08:25, Sironi, Filippo wrote:
>> On 16. May 2019, at 15:56, Graf, Alexander wrote:
>>
>> On 14.05.19 08:16, Filippo Sironi wrote:
>>> On x86, we report the UUID in DMI System Information (i.e., DMI Type 1)
>>> as VM UUID.
>>>
>>> Signed-off-by: Filippo Sironi
>>> ---
>>>
Anthony PERARD writes ("Re: [Xen-devel] [qemu-upstream-4.12-testing test]
136177: regressions - FAIL"):
> On Wed, May 15, 2019 at 04:28:35PM +, osstest service owner wrote:
> > flight 136177 qemu-upstream-4.12-testing real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/136177/
>
> On 16. May 2019, at 15:56, Graf, Alexander wrote:
>
> On 14.05.19 08:16, Filippo Sironi wrote:
>> On x86, we report the UUID in DMI System Information (i.e., DMI Type 1)
>> as VM UUID.
>>
>> Signed-off-by: Filippo Sironi
>> ---
>> arch/x86/kernel/kvm.c | 7 +++
>> 1 file changed, 7
>>> On 16.05.19 at 17:23, wrote:
> On 16/05/2019 16:20, Jan Beulich wrote:
> On 16.05.19 at 17:11, wrote:
>>> On 26/04/2019 13:02, Andrew Cooper wrote:
On 26/04/2019 12:59, Andrew Cooper wrote:
> On 18/03/2019 16:13, Jan Beulich wrote:
>> All,
>>
>> the release is due by
On 16/05/2019 16:20, Jan Beulich wrote:
On 16.05.19 at 17:11, wrote:
>> On 26/04/2019 13:02, Andrew Cooper wrote:
>>> On 26/04/2019 12:59, Andrew Cooper wrote:
On 18/03/2019 16:13, Jan Beulich wrote:
> All,
>
> the release is due by the end of the month, but will likely
>>> On 16.05.19 at 17:11, wrote:
> On 26/04/2019 13:02, Andrew Cooper wrote:
>> On 26/04/2019 12:59, Andrew Cooper wrote:
>>> On 18/03/2019 16:13, Jan Beulich wrote:
All,
the release is due by the end of the month, but will likely don't make
it before early April. Please point
> On 16. May 2019, at 17:02, Boris Ostrovsky wrote:
>
> On 5/16/19 10:08 AM, Alexander Graf wrote:
>>
>> My point is mostly that we should be as common
>> as possible when it comes to /sys/hypervisor, so that tools don't have
>> to care about the HV they're working against.
>
> It might make
>>> On 16.05.19 at 15:37, wrote:
> Ease up XEN configuration for non-standard builds, like
> armv8 tiny config.
>
> Signed-off-by: Volodymyr Babchuk
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Am Thu, 16 May 2019 16:03:55 +0100
schrieb Wei Liu :
> Does this make sense?
Sure, I was looking at the wrong function.
Doing it within libxl_domain_need_memory will certainly work.
Thanks!
Olaf
pgpJFwebL9FWO.pgp
Description: Digitale Signatur von OpenPGP
On 5/16/19 10:08 AM, Alexander Graf wrote:
>
> My point is mostly that we should be as common
> as possible when it comes to /sys/hypervisor, so that tools don't have
> to care about the HV they're working against.
It might make sense to have a common sys-hypervisor.c file
On Thu, May 16, 2019 at 03:54:55PM +0200, Olaf Hering wrote:
> Am Thu, 16 May 2019 14:46:53 +0100
> schrieb Wei Liu :
>
> > Can you clarify?
>
> create_domain has a libxl_domain_config on its stack. This is passed to
> freemem, and libxl_domain_need_memory modifies it as needed.
> The
On 26/04/2019 13:02, Andrew Cooper wrote:
> On 26/04/2019 12:59, Andrew Cooper wrote:
>> On 18/03/2019 16:13, Jan Beulich wrote:
>>> All,
>>>
>>> the release is due by the end of the month, but will likely don't make
>>> it before early April. Please point out backports you find missing from
>>>
>>> On 16.05.19 at 16:07, wrote:
> --- a/xen/drivers/video/vesa.c
> +++ b/xen/drivers/video/vesa.c
> @@ -40,6 +40,11 @@ static int __init parse_font_height(const char *s)
> }
> custom_param("font", parse_font_height);
>
> +static inline paddr_t lfb_base(void)
> +{
> +return
>>> On 16.05.19 at 15:52, wrote:
> On Wed, May 08, 2019 at 06:48:16AM -0600, Jan Beulich wrote:
>> action->ack_type is set once before the timer even gets initialized, and
>> is never changed later. The timer gets activated only for EOI and UNMASK
>> types. Hence there's no need to have a
>>> On 16.05.19 at 15:51, wrote:
> On 16/05/2019 15:05, Jan Beulich wrote:
> On 06.05.19 at 08:56, wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -154,6 +154,24 @@ static void idle_loop(void)
>>> }
>>> }
>>>
>>> +/*
>>> + * Idle loop for siblings of
On 16.05.19 17:28, Julien Grall wrote:
Well, if you fail the check then it means someone was modifying it behind your
back. That someone could update the runstate with the new information once it
is modified. So I can't see issue with not updating the runstate in the context
switch.
Hi Andrii,
On 16/05/2019 15:25, Andrii Anisov wrote:
Hello Julien,
On 16.05.19 16:48, Julien Grall wrote:
The lock can be completely removed anyway. See my previous comments.
You suggested kinda simplified try_lock with runstate update skipping in case of
fail.
The question here is if we
Hello Julien,
On 16.05.19 16:48, Julien Grall wrote:
The lock can be completely removed anyway. See my previous comments.
You suggested kinda simplified try_lock with runstate update skipping in case
of fail.
The question here is if we are OK with not updating runstate under
circumstances?
On 16.05.19 07:02, Andrew Cooper wrote:
> On 16/05/2019 14:50, Alexander Graf wrote:
>> On 14.05.19 08:16, Filippo Sironi wrote:
>>> Start populating /sys/hypervisor with KVM entries when we're running on
>>> KVM. This is to replicate functionality that's available when we're
>>> running on Xen.
On some machines (for example Thinkpad P52), UEFI GOP reports
framebuffer located above 4GB (0x40 on that machine). This
address does not fit in {xen,dom0}_vga_console_info.u.vesa_lfb.lfb_base
field, which is 32bit. The overflow here cause all kind of memory
corruption when anything tries
A bunch of fixes for booting Xen on Thinkpad P52, through grub2-efi +
multiboot2. Most of them can be applied independently.
Changes in v3:
- updated "xen: fix handling framebuffer located above 4GB"
- dropped already applied patches
---
cc: Andrew Cooper
cc: George Dunlap
cc: Ian Jackson
On 16/05/2019 14:50, Alexander Graf wrote:
> On 14.05.19 08:16, Filippo Sironi wrote:
>> Start populating /sys/hypervisor with KVM entries when we're running on
>> KVM. This is to replicate functionality that's available when we're
>> running on Xen.
>>
>> Start with /sys/hypervisor/uuid, which
On 16/05/2019 14:17, Andre Przywara wrote:
On Thu, 16 May 2019 17:15:36 +0530
Amit Tomer wrote:
On Thu, May 16, 2019 at 12:25 AM Oleksandr wrote:
On 03.05.19 20:02, Amit Singh Tomar wrote:
Suggested-by: Julien Grall
Signed-off-by: Amit Singh Tomar
---
* This replaces following
On 14.05.19 08:16, Filippo Sironi wrote:
> On x86, we report the UUID in DMI System Information (i.e., DMI Type 1)
> as VM UUID.
>
> Signed-off-by: Filippo Sironi
> ---
> arch/x86/kernel/kvm.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/x86/kernel/kvm.c
Am Thu, 16 May 2019 14:46:53 +0100
schrieb Wei Liu :
> Can you clarify?
create_domain has a libxl_domain_config on its stack. This is passed to
freemem, and libxl_domain_need_memory modifies it as needed.
The modification will go through libxl_domain_create_new, do_domain_create,
On Wed, May 08, 2019 at 06:48:16AM -0600, Jan Beulich wrote:
> action->ack_type is set once before the timer even gets initialized, and
> is never changed later. The timer gets activated only for EOI and UNMASK
> types. Hence there's no need to have a respective if() in there. Replace
> it by an
On 14.05.19 08:16, Filippo Sironi wrote:
> Start populating /sys/hypervisor with KVM entries when we're running on
> KVM. This is to replicate functionality that's available when we're
> running on Xen.
>
> Start with /sys/hypervisor/uuid, which users prefer over
>
On 16/05/2019 15:05, Jan Beulich wrote:
On 06.05.19 at 08:56, wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -154,6 +154,24 @@ static void idle_loop(void)
>> }
>> }
>>
>> +/*
>> + * Idle loop for siblings of active schedule items.
>> + * We don't do any
On Wed, May 08, 2019 at 06:47:34AM -0600, Jan Beulich wrote:
> This is a timer handler, so it gets entered with IRQs enabled. Therefore
> there's no need to save/restore the IRQ masking flag.
>
> Additionally the final switch()'es ACKTYPE_EOI case re-acquires the lock
> just for it to be dropped
On 16/05/2019 14:30, Andrii Anisov wrote:
Hello Jan,
On 16.05.19 15:09, Jan Beulich wrote:
On 23.04.19 at 10:10, wrote:
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -163,15 +163,23 @@ struct vcpu
void *sched_priv; /* scheduler-specific data */
On Thu, May 16, 2019 at 03:36:01PM +0200, Olaf Hering wrote:
> Am Thu, 16 May 2019 14:30:13 +0100
> schrieb Wei Liu :
>
> > Would the following work?
>
> This is not exactly the same because that copy will end up in
> libxl__domain_set_device_model, and we are back to square #1.
I'm not sure I
On Thu, May 16, 2019 at 06:02:15AM -0600, Jan Beulich wrote:
> >>> On 16.05.19 at 13:37, wrote:
> > On Wed, May 08, 2019 at 06:46:51AM -0600, Jan Beulich wrote:
> >> There's no point entering the loop in the function in this case. Instead
> >> there still being something in flight _after_ the
On 16/05/2019 14:23, Wei Liu wrote:
> On Wed, May 15, 2019 at 01:55:30PM +0100, Anthony PERARD wrote:
>> On Wed, May 15, 2019 at 01:07:03PM +0100, Andrew Cooper wrote:
>>> On 15/05/2019 12:40, Anthony PERARD wrote:
This was probably useful to load ELF Note, but now ELF notes
"should live
As build system now supports *_defconfig rules it is good to be able
to configure minimal XEN image with
make tiny64_defconfig
command.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/configs/{tiny64.conf => tiny64_defconfig} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename
Ease up XEN configuration for non-standard builds, like
armv8 tiny config.
Signed-off-by: Volodymyr Babchuk
---
Changes from v2:
- remove %_defconfig rule in favor of list of real *_defconfig files
Makefile | 4
xen/Makefile | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
Am Thu, 16 May 2019 14:30:13 +0100
schrieb Wei Liu :
> Would the following work?
This is not exactly the same because that copy will end up in
libxl__domain_set_device_model, and we are back to square #1.
Olaf
pgpcjNNwubdpG.pgp
Description: Digitale Signatur von OpenPGP
Hello Jan,
On 16.05.19 15:09, Jan Beulich wrote:
On 23.04.19 at 10:10, wrote:
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -163,15 +163,23 @@ struct vcpu
void*sched_priv;/* scheduler-specific data */
struct vcpu_runstate_info runstate;
+
+
On Thu, May 16, 2019 at 03:18:19PM +0200, Olaf Hering wrote:
> Am Thu, 16 May 2019 12:39:02 +0100
> schrieb Wei Liu :
>
> > autotools shipped in all the distros we care about
>
> I see autoconf 2.69 is available practically everywhere, starting
> with openSUSE 12.2, which was released in Q3
Hello Jan,
On 16.05.19 15:09, Jan Beulich wrote:
On 23.04.19 at 10:10, wrote:
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -163,15 +163,23 @@ struct vcpu
void*sched_priv;/* scheduler-specific data */
struct vcpu_runstate_info runstate;
+
+
On Thu, May 16, 2019 at 02:50:00PM +0200, Olaf Hering wrote:
> In commit 3802ecbaa9 ("libxl: add helper function to set
> device_model_version") an assert was added to
> libxl__domain_build_info_setdefault to make sure callers provide
> complete info to this function. This unveiled a flaw in the
On Wed, May 15, 2019 at 01:55:30PM +0100, Anthony PERARD wrote:
> On Wed, May 15, 2019 at 01:07:03PM +0100, Andrew Cooper wrote:
> > On 15/05/2019 12:40, Anthony PERARD wrote:
> > > This was probably useful to load ELF Note, but now ELF notes
> > > "should live in a PT_NOTE segment" (elfnote.h).
>
The patch resolves 'xencov' crashes in case of Aarch64.
All the .init.* sections are stripped after boot,
it means that anything in .init.data cannot be accessed anymore.
The build system explicitly compiles any .init binary without gcov option.
The problem is coming from libfdt and libelf.
The
Am Thu, 16 May 2019 12:39:02 +0100
schrieb Wei Liu :
> autotools shipped in all the distros we care about
I see autoconf 2.69 is available practically everywhere, starting
with openSUSE 12.2, which was released in Q3 2012. SLE11, which
can not be properly supported anymore, had autoconf 2.63.
On Thu, 16 May 2019 17:15:36 +0530
Amit Tomer wrote:
Hi,
> Thanks for having a look at it.
>
> On Thu, May 16, 2019 at 12:25 AM Oleksandr wrote:
> >
> >
> > On 03.05.19 20:02, Amit Singh Tomar wrote:
> >
> > Hi, Amit
> >
> > > XEN should not forward PPIs to Dom0 as it only support SPIs.
> >
On 16/05/2019 14:42, Jan Beulich wrote:
On 06.05.19 at 08:56, wrote:
>> Instead of dynamically decide whether the previous vcpu was using full
>> or default GDT just add a percpu variable for that purpose. This at
>> once removes the need for testing vcpu_ids to differ twice.
>>
>> Cache the
>>> On 16.05.19 at 14:46, wrote:
> On 16/05/2019 14:20, Jan Beulich wrote:
> On 06.05.19 at 08:56, wrote:
>>> --- a/xen/common/schedule.c
>>> +++ b/xen/common/schedule.c
>>> @@ -314,14 +314,42 @@ static struct sched_item *sched_alloc_item(struct
>>> vcpu *v)
>>> return NULL;
>>> }
>>>
>>> On 06.05.19 at 08:56, wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -154,6 +154,24 @@ static void idle_loop(void)
> }
> }
>
> +/*
> + * Idle loop for siblings of active schedule items.
> + * We don't do any standard idle work like tasklets, page scrubbing or
On 16/05/2019 14:30, Jan Beulich wrote:
On 06.05.19 at 08:56, wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -1619,6 +1619,37 @@ static inline bool need_full_gdt(const struct domain
>> *d)
>> return is_pv_domain(d) && !is_idle_domain(d);
>> }
>>
>>
In commit 3802ecbaa9 ("libxl: add helper function to set
device_model_version") an assert was added to
libxl__domain_build_info_setdefault to make sure callers provide
complete info to this function. This unveiled a flaw in the way how
libxl_domain_build_info is passed to libxl. The public API
On Thu, May 16, 2019 at 02:18:05PM +0200, Olaf Hering wrote:
> Am Thu, 16 May 2019 14:04:51 +0200
> schrieb Olaf Hering :
>
> > There are quite a few checks for device_model_version, they would be all
> > wrong if the assert is removed, or changed back to QEMU_XEN. Perhaps we
> > can continue to
On Thu, May 16, 2019 at 01:44:32PM +0200, Olaf Hering wrote:
> Am Thu, 16 May 2019 12:39:02 +0100
> schrieb Wei Liu :
>
> > I guess all I can say at this point is that I haven't done a survey on
> > the differences of the autotools shipped in all the distros we care
> > about (especially the
On 16/05/2019 14:20, Jan Beulich wrote:
On 06.05.19 at 08:56, wrote:
>> --- a/xen/common/schedule.c
>> +++ b/xen/common/schedule.c
>> @@ -314,14 +314,42 @@ static struct sched_item *sched_alloc_item(struct vcpu
>> *v)
>> return NULL;
>> }
>>
>> -int sched_init_vcpu(struct vcpu *v,
On Thu, May 16, 2019 at 01:42:55PM +0200, Roger Pau Monné wrote:
> On Thu, May 16, 2019 at 12:24:50PM +0100, Wei Liu wrote:
> > On Thu, May 16, 2019 at 12:57:35PM +0200, Olaf Hering wrote:
> > > Am Thu, 16 May 2019 12:45:40 +0200
> > > schrieb Roger Pau Monné :
> > >
> > > > Having a field in
>>> On 06.05.19 at 08:56, wrote:
> Instead of dynamically decide whether the previous vcpu was using full
> or default GDT just add a percpu variable for that purpose. This at
> once removes the need for testing vcpu_ids to differ twice.
>
> Cache the need_full_gdt(nd) value in a local variable.
>>> On 06.05.19 at 08:56, wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1619,6 +1619,37 @@ static inline bool need_full_gdt(const struct domain
> *d)
> return is_pv_domain(d) && !is_idle_domain(d);
> }
>
> +static inline void write_full_gdt_ptes(seg_desc_t
On 16/05/2019 12:48, wencongyang (A) wrote:
>
> On 2019/5/16 15:58, Andrew Cooper wrote:
>> On 16/05/2019 08:56, wencongyang (A) wrote:
>>> On 2019/5/16 15:38, Andrew Cooper wrote:
On 16/05/2019 03:46, wencongyang (A) wrote:
> Hi all
>
> Fill buffers, load ports are shared between
Hi All,
Thank you for replies. Will do all the mentioned updates and will send
patch v2 after retesting it on target board (with libelf Makefile
update).
Thanks
On Thu, May 16, 2019 at 2:40 PM Wei Liu wrote:
>
> On Thu, May 16, 2019 at 11:37:33AM +, Julien Grall wrote:
> >
> >
> > On
>>> On 06.05.19 at 08:56, wrote:
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -314,14 +314,42 @@ static struct sched_item *sched_alloc_item(struct vcpu
> *v)
> return NULL;
> }
>
> -int sched_init_vcpu(struct vcpu *v, unsigned int processor)
> +static unsigned int
Am Thu, 16 May 2019 14:04:51 +0200
schrieb Olaf Hering :
> There are quite a few checks for device_model_version, they would be all
> wrong if the assert is removed, or changed back to QEMU_XEN. Perhaps we
> can continue to live with that error. device_model_version could become
> a local
flight 136364 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136364/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 136309
>>> On 23.04.19 at 10:10, wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -163,15 +163,23 @@ struct vcpu
> void*sched_priv;/* scheduler-specific data */
>
> struct vcpu_runstate_info runstate;
> +
> +spinlock_t mapped_runstate_lock;
Am Thu, 16 May 2019 12:50:43 +0100
schrieb Wei Liu :
> Adding new APIs and defining LIBXL_HAVE won't get you out of this hole.
From what I see, src/libxl/libxl_conf.c:libxlBuildDomainConfig would need
to call libxl_domain_config_finish(libxl_domain_config*) at the end of
that function, wrapped
>>> On 16.05.19 at 13:37, wrote:
> On Wed, May 08, 2019 at 06:46:51AM -0600, Jan Beulich wrote:
>> There's no point entering the loop in the function in this case. Instead
>> there still being something in flight _after_ the loop would be an
>> actual problem: No timer would be running anymore
Am Thu, 16 May 2019 13:38:57 +0200
schrieb Olaf Hering :
> To me it looks like something like
> libxl_domain_config_finish(libxl_domain_config*)
> is missing now.
If we do not want to add a new API, a hack might be to use container_of()
and assume that the libxl_domain_build_info passed to
1 - 100 of 156 matches
Mail list logo
