flight 171711 qemu-mainline real [real]
flight 171714 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171711/
http://logs.test-lab.xenproject.org/osstest/logs/171714/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
I really appreciate your kind reply.
I'm still looking for a possible method to send via git send-email.
If I cannot find an appropriate method, I will send a patch as an attachment and content in the mail.
Thank you so much.
Best Regards,
Bo youn Park.
- O
flight 171709 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171709/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 171681
test-armhf-armhf-libvirt 16 saver
flight 171706 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171706/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 171702
test-armhf-armhf-xl-rtds
flight 171710 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171710/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3b8cee1781c4149c7a762b8a1c8115b635cf4cad
baseline version:
ovmf 48249243777882d7d89ca
flight 171708 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171708/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Thu, Jul 14, 2022 at 01:51:06PM +0200, Jan Beulich wrote:
> On 06.07.2022 17:32, Marek Marczykowski-Górecki wrote:
> > +/*
> > + * Don't place anything else on this page - it will be
> > + * DMA-reachable by the USB controller.
> > + */
> > +char _pad[0] __aligned(XUE_PAGE_SI
On Thu, Jul 14, 2022 at 01:58:25PM +0200, Jan Beulich wrote:
> On 06.07.2022 17:32, Marek Marczykowski-Górecki wrote:
> > +static int xue_init_dbc(struct xue *xue)
> > +{
> > +uint64_t erdp = 0;
> > +uint64_t out = 0;
> > +uint64_t in = 0;
> > +uint64_t mbs = 0;
> > +struct xue_
flight 171704 qemu-mainline real [real]
flight 171707 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171704/
http://logs.test-lab.xenproject.org/osstest/logs/171707/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
Currently the vPMU state from a parent isn't copied to VM forks. To enable the
vPMU state to be copied to a fork VM we export certain vPMU functions. First,
the vPMU context needs to be allocated for the fork if the parent has one. For
this we introduce vpmu->allocate_context, which has previously
From: Julien Grall
At the moment, xen_second is used to cover the first 2GB of the
virtual address space. With the recent rework of the page-tables,
only the first 1GB region (where Xen resides) is effectively used.
In addition to that, I would like to reshuffle the memory layout.
So Xen mapping
From: Julien Grall
The file xen/arch/mm.c has been growing quite a lot. It now contains
various independent part of the MM subsytem.
One of them is the helpers to map/unmap a page which is only used
by arm32 and protected by CONFIG_ARCH_MAP_DOMAIN_PAGE. Move them in a
new file xen/arch/arm/domai
From: Julien Grall
move it to Kconfig.
The define CONFIG_DOMAIN_PAGE indicates whether the architecture provide
helpers to map/unmap a domain page. Rename it to the define to
CONFIG_ARCH_MAP_DOMAIN_PAGE so it is clearer that this will not remove
support for domain page (this is not a concept tha
From: Julien Grall
At the moment, the domheap mappings initialization is done separately for
the boot CPU and secondary CPUs. The main difference is for the former
the pages are part of Xen binary whilst for the latter they are
dynamically allocated.
It would be good to have a single helper so i
From: Julien Grall
At the moment, *_VIRT_END may either point to the address after the end
or the last address of the region.
The lack of consistency make quite difficult to reason with them.
Furthermore, there is a risk of overflow in the case where the address
points past to the end. I am not
From: Julien Grall
Hi all,
This series is a collection of patches to clean-up the MM subsystem
I have done in preparation for the next revision of "xen/arm: Don't
switch TTBR while the MMU is on" [1].
Cheers,
[1] https://lore.kernel.org/all/20220309112048.17377-1-jul...@xen.org/
Julien Grall
Hello Wei,
Wei Chen writes:
> Hi Volodymyr,
>
> On 2022/7/19 5:15, Volodymyr Babchuk wrote:
>> From: Oleksandr Andrushchenko
>
>> if ( !use_msi )
>> return -EOPNOTSUPP;
>> diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
>> index 938821e593..f93922a
On 7/15/22 15:25, Julien Grall wrote:
> Hi Daniel,
>
> On 06/07/2022 22:04, Daniel P. Smith wrote:
>> The x86 and Arm architectures represent in memory the general boot
>> information
>> and boot modules differently despite having commonality. The x86
>> representations are bound to the multiboot
On Wed, 20 Jul 2022, Jan Beulich wrote:
On 20.07.2022 06:48, ChrisD wrote:
So, you think it's a problem with fc36?
Just to also state it here - it turns out we need to tell the compiler
to avoid MMX insns. A patch for this was already sent and ack-ed.
I have done a temporary build of xen fo
Hi Jan,
On 19/07/2022 07:01, Jan Beulich wrote:
On 18.07.2022 19:39, Julien Grall wrote:
On 18/07/2022 12:02, Jan Beulich wrote:
On 18.07.2022 12:24, Julien Grall wrote:
3)
unsigned int inc_order = min(MAX_ORDER, flsl(e - s) - 1);
if ( s )
inc_order = min(inc
Hi Oleksandr,
On 16/07/2022 16:29, Oleksandr Tyshchenko wrote:
On 16/07/2022 15:56, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Borrow the x86's check from p2m_remove_page() which was added
by the following commit: c65ea16dbcafbe4fe21693b18f8c2a3c5d14600e
"x86/p2m: don't assert tha
On Wed, Jul 20, 2022 at 05:24:22PM +0100, Anthony PERARD wrote:
>
> I think that this `xl` process just wait for the domain to shutdown
> or die. When we run `xl create`, before exiting there's a fork/exec of
> xl which handle a few domain events, so it looks like this stack trace
> is expected (a
> I think that this `xl` process just wait for the domain to shutdown
> or die. When we run `xl create`, before exiting there's a fork/exec of
> xl which handle a few domain events, so it looks like this stack trace
> is expected (and look like the one I have). So it don't looks like to be
> the xl
flight 171705 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171705/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Wed, Jul 20, 2022 at 03:04:22PM +, Mathieu Tarral wrote:
> Hi Anthony
>
>
> > $(debug) controls the level of optimisation of the compilation to make
> > it easier to debug.
> >
> > So, with debug=y, we have libxenstore having issue with killing the
> > its reading thread? :-(
> > Maybe tha
On Mon, Jul 18, 2022 at 12:21:25PM +0300, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Re-generate goland bindings to reflect changes to libxl_types.idl
> from the following commit:
> 54d8f27d0477 tools/libxl: report trusted backend status to frontends
>
> Signed-off-by: Oleksand
On Sat, Jul 16, 2022 at 07:37:45PM +0300, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This patch adds basic support for configuring and assisting virtio-mmio
> based virtio-disk backend (emulator) which is intended to run out of
> Qemu and could be run in any domain.
> Although t
Hi Anthony
> $(debug) controls the level of optimisation of the compilation to make
> it easier to debug.
>
> So, with debug=y, we have libxenstore having issue with killing the
> its reading thread? :-(
> Maybe that reading thread is doing something that can't be stopped,
> maybe it's waiting fo
CCing Juergen and xen-devel.
On Mon, Jul 18, 2022 at 06:25:54PM +, Mathieu Tarral wrote:
> Using gdb to debug the xl process, I get the following stacktrace:
>
> (gdb) bt
> #0 __futex_abstimed_wait_common64 (private=128, cancel=true, abstime=0x0,
> op=265, expected=8652, futex_word=0x7f6deb
On 20.07.2022 06:48, ChrisD wrote:
> So, you think it's a problem with fc36?
Just to also state it here - it turns out we need to tell the compiler
to avoid MMX insns. A patch for this was already sent and ack-ed.
Jan
On 20/07/2022 14:36, Jan Beulich wrote:
> On 20.07.2022 15:33, Andrew Cooper wrote:
>> On 20/07/2022 14:30, Jan Beulich wrote:
>>> Passing -mno-sse alone is not enough: The compiler may still find
>>> (questionable) reasons to use MMX insns. In particular with gcc12 use
>>> of MOVD+PUNPCKLDQ+MOVQ w
On 20.07.2022 15:33, Andrew Cooper wrote:
> On 20/07/2022 14:30, Jan Beulich wrote:
>> Passing -mno-sse alone is not enough: The compiler may still find
>> (questionable) reasons to use MMX insns. In particular with gcc12 use
>> of MOVD+PUNPCKLDQ+MOVQ was observed in an apparent attempt to auto-
>>
On 20.07.2022 13:16, Julien Grall wrote:
> On 20/07/2022 10:59, Rahul Singh wrote:
>>> On 13 Jul 2022, at 1:29 pm, Julien Grall wrote:
>>> On 13/07/2022 13:12, Bertrand Marquis wrote:
> On 13 Jul 2022, at 12:31, Julien Grall wrote:
>> I can't
>> see why it would be wrong to have a mor
On 20/07/2022 14:30, Jan Beulich wrote:
> Passing -mno-sse alone is not enough: The compiler may still find
> (questionable) reasons to use MMX insns. In particular with gcc12 use
> of MOVD+PUNPCKLDQ+MOVQ was observed in an apparent attempt to auto-
> vectorize the storing of two adjacent zeroes, 3
Passing -mno-sse alone is not enough: The compiler may still find
(questionable) reasons to use MMX insns. In particular with gcc12 use
of MOVD+PUNPCKLDQ+MOVQ was observed in an apparent attempt to auto-
vectorize the storing of two adjacent zeroes, 32 bits each.
Reported-by: ChrisD
Signed-off-by
On 20.07.2022 13:28, Jan Beulich wrote:
> On 20.07.2022 12:02, Andrew Cooper wrote:
>> On 20/07/2022 09:19, Jan Beulich wrote:
>>> On 20.07.2022 06:48, ChrisD wrote:
So, you think it's a problem with fc36?
>>> Well, if that's where the binary came from, then yes.
>>
>> So
>> https://kojipkgs.f
On 20.07.2022 12:02, Andrew Cooper wrote:
> One observation though. We do pass -mno-sse but not -mno-mmx. I still
> can't figure out what makes the compiler think there's any SIMD to be
> done in this function.
So this looks to be "optimization", done in a few more places. The pattern
is always
flight 171702 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171702/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-pair 11 xen-install/dst_host fail in 171695 pass in 171702
test-amd64-i386-xl-qemuu-dmrestr
On Tue, Jul 19, 2022 at 4:29 PM Andrew Cooper wrote:
>
> On 19/07/2022 21:08, Jason Andryuk wrote:
> > commit e46474278a0e ("x86/intel: Expose MSR_ARCH_CAPS to dom0") started
> > exposing MSR_ARCH_CAPS to dom0. More bits in MSR_ARCH_CAPS have since
> > been defined, but they haven't been exposed.
On 20.07.2022 12:02, Andrew Cooper wrote:
> On 20/07/2022 09:19, Jan Beulich wrote:
>> On 20.07.2022 06:48, ChrisD wrote:
>>> So, you think it's a problem with fc36?
>> Well, if that's where the binary came from, then yes.
>
> So
> https://kojipkgs.fedoraproject.org//packages/xen/4.16.1/4.fc36/dat
On 20.07.2022 12:02, Andrew Cooper wrote:
> On 20/07/2022 09:19, Jan Beulich wrote:
>> On 20.07.2022 06:48, ChrisD wrote:
>>> So, you think it's a problem with fc36?
>> Well, if that's where the binary came from, then yes.
>
> So
> https://kojipkgs.fedoraproject.org//packages/xen/4.16.1/4.fc36/dat
Hi Rahul,
On 20/07/2022 10:59, Rahul Singh wrote:
On 13 Jul 2022, at 1:29 pm, Julien Grall wrote:
On 13/07/2022 13:12, Bertrand Marquis wrote:
On 13 Jul 2022, at 12:31, Julien Grall wrote:
I can't
see why it would be wrong to have a more tight limit on static ports
than on traditional ("d
flight 171703 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171703/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 48249243777882d7d89ca0b86c89e355b5f941f3
baseline version:
ovmf 24eac4caf31afae48349a
On 20/07/2022 09:19, Jan Beulich wrote:
> On 20.07.2022 06:48, ChrisD wrote:
>> So, you think it's a problem with fc36?
> Well, if that's where the binary came from, then yes.
So
https://kojipkgs.fedoraproject.org//packages/xen/4.16.1/4.fc36/data/logs/x86_64/build.log
is the build log.
For iommu_
Hi ,
> On 13 Jul 2022, at 1:29 pm, Julien Grall wrote:
>
>
>
> On 13/07/2022 13:12, Bertrand Marquis wrote:
>>> On 13 Jul 2022, at 12:31, Julien Grall wrote:
I can't
see why it would be wrong to have a more tight limit on static ports
than on traditional ("dynamic") ones. Even
On 19.07.2022 19:18, Tamas K Lengyel wrote:
> --- a/xen/arch/x86/include/asm/vpmu.h
> +++ b/xen/arch/x86/include/asm/vpmu.h
> @@ -40,6 +40,7 @@
> /* Arch specific operations shared by all vpmus */
> struct arch_vpmu_ops {
> int (*initialise)(struct vcpu *v);
> +int (*allocate_context)(st
On 20.07.2022 06:48, ChrisD wrote:
> So, you think it's a problem with fc36?
Well, if that's where the binary came from, then yes.
And btw please don't top-post and please don't send html mail
(see the almost unreadable stuff below that was how your mail
came through when read as plain-text).
Ja
On 20.07.2022 10:11, Jan Beulich wrote:
> On 20.07.2022 02:33, Dylanger Daly wrote:
>>> I'd focus on the booting issues first. And I guess you can take a video
>>> of that (assuming that a single screenshot likely isn't going to be
>>> enough), possibly with "vga=keep" in place (albeit that introdu
On 20.07.2022 02:33, Dylanger Daly wrote:
>> I'd focus on the booting issues first. And I guess you can take a video
>> of that (assuming that a single screenshot likely isn't going to be
>> enough), possibly with "vga=keep" in place (albeit that introduces
>> extra slowness)?
>>
>> There's also th
On 20.07.22 06:29, Jiamei Xie wrote:
> Hi Oleksandr,
Hello Jiamei
>
> We have tested it on arm64 with " disk = [ 'phy:/usr/share/guests/disk.img0,
> xvda1, backendtype=standalone, specification=virtio']". It works ok.
>
> Tested-by: Jiamei Xie
> Tested-by: Henry Wang
Thank you for the test
flight 171696 ovmf real [real]
flight 171699 ovmf real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171696/
http://logs.test-lab.xenproject.org/osstest/logs/171699/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-
On 19.07.2022 19:02, Daniel P. Smith wrote:
> On 7/19/22 05:32, Jan Beulich wrote:
>> On 06.07.2022 23:04, Daniel P. Smith wrote:
>>> --- a/xen/arch/x86/efi/efi-boot.h
>>> +++ b/xen/arch/x86/efi/efi-boot.h
>>> @@ -18,7 +18,7 @@ static multiboot_info_t __initdata mbi = {
>>> * The array size needs
52 matches
Mail list logo
