>>> On 17.05.19 at 07:13, wrote:
> 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 voi
flight 136266 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136266/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 133596
build-i386-prev
On Thu, May 16, 2019 at 06:40:14PM +0100, Julien Grall wrote:
>
> No need to resend the patch, I can do the modification when I will commit the
> patch.
>
Hi Julien,
Thank you for detailed description provided.
Will take into consideration all the notes.
Thanks
> On May 13, 2019, at 11: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?
As discussed F2F in a Xen Summit 2017 design session: OpenXT and Citrix
XenServer use blktap. VHD encryption support was recently upst
>>> On 16.05.19 at 21:30, wrote:
> 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 co
>>> On 16.05.19 at 18:21, wrote:
> Sorry, but I think it may be best to wait. I'm open to being
> persuaded...
Okay - as also indicated on irc, with the weekend in between and
with the most recent flight having failed anyway it shouldn't be
too much of an extra delay. Yet to be honest - most or
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. A
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 archite
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 everywhere,
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 git://xenbits.xen.org/osstest/ovmf.gi
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
build-amd64-pre
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 register
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 D
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
b/xen/include/asm-x86/mem
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 i
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 1
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
test-amd64-i386-exam
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
test-armhf-
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 Syst
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 .init.d
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 boar
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 a
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 sho
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.
Sign
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 sooner
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 perhap
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 (las
>>> 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 1
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 ma
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 corresponde
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 t
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 interf
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
>>> ---
>>> arch/x86/ker
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 insert
>>> 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 don't
>>> 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 s
>>> 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
https://lists.xenp
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
(drivers/hypervisor/sys-
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 modificatio
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
>>> th
>>> 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 (paddr_t)((vlfb
>>> 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 respecti
>>> 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 acti
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.
That's
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 a
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?
T
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 t
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
cc
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 use
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 pat
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 b/arch/x86/kerne
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,
initiate_domain_
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 AS
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
> /sys/devices/virtual/dmi/id/prod
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 sta
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 a
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 */
str
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 f
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 loop
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 xen/
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(-)
di
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;
+
+s
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 2012
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;
+
+s
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 wa
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 en
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.
O
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);
>> }
>>
>> +static
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
libx
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 l
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 older
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, un
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 buil
>>> 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 *gdt,
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 16/05/
>>> 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 sche
1 - 100 of 159 matches
Mail list logo
