flight 138758 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138758/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0a487ef96bd6d2e0ac23323adab86f9949068ed6
baseline version:
ovmf e54ce6d074283b568a128
flight 138754 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138754/
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. 133580
build-armhf-pvops
flight 138766 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138766/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd broken
build-amd64-freebs
flight 138748 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138748/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx broken
build-amd64-prev 6 xen-bu
So,
> I am going to try to expose the whole crossbar to the dom0 by mapping it
> into dom0 and after that to unmap it and restrict the use of the control
> register via register_mmio_handler. Don't know whether this will work.
>
I tried and write now now visible progress:
--- a/xen/arch/arm/pla
flight 138747 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138747/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx broken
build-amd64-prev 6 xen-bu
flight 138745 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138745/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 138717
test-amd64-amd64-xl-qemuu-win7-amd64
>>> On 05.06.19 at 08:51, wrote:
> First and foremost make timer_softirq_action() avoid growing the heap
> if its new size can't be stored without truncation. 64k entries is a
> lot, and I don't think we're at risk of actually running into the issue,
> but I also think it's better not to allow for
On 05.07.2019 17:06, Alexandru Stefan ISAILA wrote:
>> On 03.07.2019 14:50, Alexandru Stefan ISAILA wrote:
>> And then I would of course have wished that a cleanup patch like this
>> one dealt with both sides, i.e. removed pt sharing remains from
>> xen/drivers/passthrough/amd/ at the same time (i.
On 05/07/2019 16:31, Jan Beulich wrote:
> --- a/xen/arch/x86/mm/shadow/private.h
> +++ b/xen/arch/x86/mm/shadow/private.h
> @@ -709,11 +709,26 @@ struct sh_emulate_ctxt {
> #endif
> };
>
> +#ifdef CONFIG_HVM
> const struct x86_emulate_ops *shadow_init_emulation(
> struct sh_emulate_c
This started out with me noticing the latent bug of there being HVM
related declarations in common.c that their producer doesn't see, and
that hence could go out of sync at any time. However, go farther than
fixing just that and move the functions actually using these into hvm.c.
This way the items
> -Original Message-
> From: Jan Beulich
> Sent: 05 July 2019 15:52
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Andrew Cooper
> ; George Dunlap ; Ian
> Jackson
> ; Stefano Stabellini ; Konrad
> Rzeszutek Wilk
> ; Tim (Xen.org) ; Wei Liu
> Subject: Re: [PA
On 07/04/19 16:41, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/ovmf.git
> br.platform-xen-pvh-v3
>
> Hi,
>
> I've started to create a Xen specific platform, in OvmfPkg/XenOvmf.dsc
> with the goal to make it work on both Xen
> On 03.07.2019 14:50, Alexandru Stefan ISAILA wrote:
>> At this moment IOMMU pt sharing is disabled by commit [1].
>>
>> This patch aims to clear the IOMMU hap share support as it will not be
>> used in the future. By doing this the IOMMU bits used in pte[52:58] can
>> be used in other ways.
>>
>
On 07/04/19 16:42, Anthony PERARD wrote:
> ACPI Timer does not work in a PVH guest, but local APIC works on both
> PVH and HVM.
>
> Note that the use of SecPeiDxeTimerLibCpu might be an issue with a
> driver of type DXE_RUNTIME_DRIVER. I've attemptde to find out which of
> the DXE_RUNTIME_DRIVER u
On 07/04/19 16:42, Anthony PERARD wrote:
> This patch allows the ResetVector to be run indenpendently from build
> time addresses.
>
> The goal of the patch is to avoid having to create RAM just below 4G
> when creating a Xen PVH guest while being compatible with the way
> hvmloader currently load
On 05.07.2019 16:48, Paul Durrant wrote:
> This patch adds XMEM_POOL_POISON to the Kconfig DEBUG options. If set,
> free blocks (greater than MIN_BLOCK_SIZE) will be poisoned with 0xAA
> bytes which will then be verified when memory is subsequently allocated.
> This can help in spotting heap corrup
This patch dispenses with the init_region. It's simply not necessary
(pools will still happily grow and shrink on demand in its absence) and the
code can be shortended by removing it. It also avoids the sole evaluation
of ADD_REGION without holding the pool lock (which is unsafe).
NOTE: The if sta
These are the remaining patches to xmalloc_tlsf.c that stem from debugging
the problem that led to commit 56ad6265 "x86/msi: fix loop termination
condition in pci_msi_conf_write_intercept()".
Paul Durrant (2):
xmalloc: remove struct xmem_pool init_region
xmalloc: add a Kconfig option to poison
On 05.07.2019 16:40, Andrew Cooper wrote:
> For now, I'm tempted to go with an answer of "it doesn't need to be the
> compat GDT".
Which is fine with me.
> This is a rabbit hole I really don't have time to follow atm.
Fully understood. From the very beginning I was only after some commit
messag
This patch adds XMEM_POOL_POISON to the Kconfig DEBUG options. If set,
free blocks (greater than MIN_BLOCK_SIZE) will be poisoned with 0xAA
bytes which will then be verified when memory is subsequently allocated.
This can help in spotting heap corruption, particularly use-after-free.
Signed-off-by
On 03.07.2019 14:50, Alexandru Stefan ISAILA wrote:
> At this moment IOMMU pt sharing is disabled by commit [1].
>
> This patch aims to clear the IOMMU hap share support as it will not be
> used in the future. By doing this the IOMMU bits used in pte[52:58] can
> be used in other ways.
>
> [1] c2
On 05/07/2019 14:56, Jan Beulich wrote:
> On 05.07.2019 15:36, Andrew Cooper wrote:
>> On 05/07/2019 11:00, Jan Beulich wrote:
>>> On 04.07.2019 19:57, Andrew Cooper wrote:
Also, it should now be very obvious to people that Xen's current GDT
handling
for non-PV vcpus is a recipe sub
On 05.07.2019 15:46, Frédéric Pierret wrote:
> I'm experiencing problem to perform PCI passthrough of Ethernet card
> with 4 ports (HP Ethernet 1Gb 4-port 331FLR Adapter) on an HP DL360 Gen8.
>
> I have two server like this one where the first is under CentOS and the
> other one, under Qubes. Und
On 07/04/19 16:42, Anthony PERARD wrote:
> As described in the Xen PVH documentation [1], "ebx: contains the
> physical memory address where the loader has placed the boot start info
> structure". To have this pointer saved to be able to use it later in the
> PEI phase, we allocate some space in th
On 07/04/19 16:42, Anthony PERARD wrote:
> Add a new entry point for Xen PVH that enter directly in 32bits.
>
> Information on the expected state of the machine when this entry point
> is used can be found at:
> https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
>
> Ref: https://bugzilla.
On 07/04/19 16:42, Anthony PERARD wrote:
> This patch changes the flash device image of OvmfXen to make it look
> like it's an ELF. For this, we replace the empty embedded variable store
> by a binary array, which is a ELF file header.
>
> The ELF header explain to a loader to load the binary at t
> -Original Message-
> From: Jan Beulich
> Sent: 05 July 2019 14:41
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Stefano
> Stabellini
> ; Konrad Rzeszutek Wilk ; Tim
> (Xen.org) ;
> Wei Liu
> Subject: Re: [PA
On Fri, 2019-07-05 at 14:17 +0100, Sergey Dyasli wrote:
> 1) This crash is quite likely to happen:
>
> [2019-07-04 18:22:46 UTC] (XEN) [ 3425.220660] Watchdog timer detects
> that CPU2 is stuck!
> [2019-07-04 18:22:46 UTC] (XEN) [ 3425.226293] [ Xen-4.13.0-
> 8.0.6-d x86_64 debug=y Not tai
On 05.07.2019 15:36, Andrew Cooper wrote:
> On 05/07/2019 11:00, Jan Beulich wrote:
>> On 04.07.2019 19:57, Andrew Cooper wrote:
>>> Also, it should now be very obvious to people that Xen's current GDT
>>> handling
>>> for non-PV vcpus is a recipe subtle bugs, if we ever manage to execute a
>>> s
On 04/07/2019 15:42, Anthony PERARD wrote:
> Add a new entry point for Xen PVH that enter directly in 32bits.
>
> Information on the expected state of the machine when this entry point
> is used can be found at:
> https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
>
> Ref: https://bugzilla.
Hi Anthony,
On 07/04/19 16:42, Anthony PERARD wrote:
> Introduce XenPlatformPei, a copy of OvmfPkg/PlatformPei without some
> of QEMU specific initialization, Xen does not support QemuFwCfg.
>
> This new module will be adjusted to accommodate Xen PVH.
>
> fw_cfg dependents that have been removed
On 05.07.2019 11:02, Paul Durrant wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -105,6 +105,13 @@ config DEBUG_TRACE
> either directly to the console or are printed to console in case of
> a system crash.
>
> +config XMEM_POOL_POISON
> + bool "Poison free
On 05/07/2019 11:00, Jan Beulich wrote:
> On 04.07.2019 19:57, Andrew Cooper wrote:
>> write_full_gdt_ptes() has a latent bug. Using virt_to_mfn() and iterating
>> with (mfn + i) is wrong, because of PDX compression. The context switch path
>> only functions correctly because NR_RESERVED_GDT_PAGE
On 07/04/19 16:42, Anthony PERARD wrote:
> OvmfXen is a copy of OvmfX64, removing VirtIO and some SMM.
>
> This new platform will be changed to make it works on two types of Xen
> guest: HVM and PVH.
>
> Compare to OvmfX64, this patch:
>
> - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINI
On 05.07.19 15:17, Sergey Dyasli wrote:
Hi Juergen,
I did some testing of this series (with sched-gran=core) and posting a couple of
crash backtraces here for your information.
Additionally, resuming a Debian 7 guest after suspend is broken.
I will be able to provide any additional information
Hi Juergen,
I did some testing of this series (with sched-gran=core) and posting a couple of
crash backtraces here for your information.
Additionally, resuming a Debian 7 guest after suspend is broken.
I will be able to provide any additional information only after XenSummit :)
1) This crash is
On 05/07/2019 13:13, Paul Durrant wrote:
>> -Original Message-
> [snip]
>> I'm completely on Jan's side here.
>>
>> What would be possible perhaps is to split ring.h into two headers: a
>> new one with the pure ring definitions and ring.h #include-ing
>> xen-compat.h and the new header and
On 7/2/19 9:19 PM, Zhenzhong Duan wrote:
> PVH guest needs PV extentions to work, so "nopv" parameter should be
> ignored for PVH but not for HVM guest.
>
> If PVH guest boots up via the Xen-PVH boot entry, xen_pvh is set early,
> we know it's PVH guest and ignore "nopv" parameter directly.
>
> If
> -Original Message-
> From: Jan Beulich
> Sent: 05 July 2019 13:54
> To: Paul Durrant
> Cc: JulienGrall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Stefano
> Stabellini
> ; xen-devel@lists.xenproject.org; KonradRzeszutek Wilk
> ; Tim (Xen.org) ; WeiLiu
> Subject: Re: [PATCH v2
On 7/2/19 9:19 PM, Zhenzhong Duan wrote:
> Clean up unnecessory code after that operation.
>
> Signed-off-by: Zhenzhong Duan
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Stefano Stabellini
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
Reviewed-by: Boris Ostrovsky
___
flight 138742 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138742/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
129313
build-armhf-
On 05.07.2019 14:18, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 05 July 2019 13:12
>>
>> On 05.07.2019 11:02, Paul Durrant wrote:
>>> @@ -352,13 +343,6 @@ void xmem_pool_destroy(struct xmem_pool *pool)
>>>if ( pool == NULL )
>>>return;
>>>
>>> -/* User is destroying
Hi Anthony,
On 07/04/19 16:41, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/ovmf.git
> br.platform-xen-pvh-v3
>
> Hi,
>
> I've started to create a Xen specific platform, in OvmfPkg/XenOvmf.dsc
> with the goal to make it wor
> -Original Message-
> From: Jan Beulich
> Sent: 05 July 2019 13:12
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Andrew Cooper
> ; George Dunlap ; Ian
> Jackson
> ; Stefano Stabellini ; Konrad
> Rzeszutek Wilk
> ; Tim (Xen.org) ; Wei Liu
> Subject: Re: [PA
> -Original Message-
[snip]
>
> I'm completely on Jan's side here.
>
> What would be possible perhaps is to split ring.h into two headers: a
> new one with the pure ring definitions and ring.h #include-ing
> xen-compat.h and the new header and #define-ing the xen*mb() macros.
>
> Not sur
On 05.07.2019 11:02, Paul Durrant wrote:
> This patch dispenses with the init_region. It's simply not necessary
> (pools will still happily grow and shrink on demand in its absence) and the
> code can be shortended by removing it. It also avoids the sole evaluation
> of ADD_REGION without holding t
flight 138763 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138763/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 05.07.19 09:59, Jan Beulich wrote:
On 04.07.2019 18:11, Paul Durrant wrote:
-Original Message-
From: Jan Beulich
Sent: 04 July 2019 16:49
To: Anthony Perard
Cc: xen-devel@lists.xenproject.org; Paul Durrant ;
Konrad Rzeszutek Wilk
; Juergen Gross
Subject: Re: [Xen-devel] [PATCH] in
On 04.07.2019 19:57, Andrew Cooper wrote:
> write_full_gdt_ptes() has a latent bug. Using virt_to_mfn() and iterating
> with (mfn + i) is wrong, because of PDX compression. The context switch path
> only functions correctly because NR_RESERVED_GDT_PAGES is 1.
Whether this is a (latent) bug depen
Hi Iain,
On 7/5/19 10:31 AM, Iain Hunter wrote:
> Hi Denis,
> That is about as far as I got
>
> The driver to handle crossbar is
> https://github.com/torvalds/linux/blob/master/drivers/irqchip/irq-crossbar.c
> The documentation is
> https://github.com/torvalds/linux/blob/master/Documentation/
flight 138746 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138746/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 138618
build-amd64-libvirt
On 04.07.2019 21:14, Andrew Cooper wrote:
> To allow for further improvements, it is useful to be able to clear more than
> a single flag at once. Rework gnttab_clear_flag() into gnttab_clear_flags()
> which takes a bitmask rather than a bit number.
>
> No practical change yet.
>
> Signed-off-by
> -Original Message-
> From: Paul Durrant
> Sent: 05 July 2019 10:03
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Jan Beulich
> ;
> Julien Grall ; Konrad Rzeszutek Wilk
> ; Stefano
> Stabellini ; Tim (Xen.org) ; Wei Liu
>
These are the remaining patches to xmalloc_tlsf.c that stem from debugging
the problem that led to commit 56ad6265 "x86/msi: fix loop termination
condition in pci_msi_conf_write_intercept()".
Paul Durrant (2):
xmalloc: remove struct xmem_pool init_region
xmalloc: add a Kconfig option to poison
This patch dispenses with the init_region. It's simply not necessary
(pools will still happily grow and shrink on demand in its absence) and the
code can be shortended by removing it. It also avoids the sole evaluation
of ADD_REGION without holding the pool lock (which is unsafe).
Signed-off-by: P
This patch adds XMEM_POOL_POISON to the Kconfig DEBUG options. If set,
free blocks (greater than MIN_BLOCK_SIZE) will be poisoned with 0xAA
bytes which will then be verified when memory is subsequently allocated.
This can help in spotting heap corruption, particularly use-after-free.
Signed-off-by
flight 138740 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138740/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 137600
test-armhf-armhf-libvirt 14 sav
Hi Denis,
That is about as far as I got
The driver to handle crossbar is
https://github.com/torvalds/linux/blob/master/drivers/irqchip/irq-crossbar.c
The documentation is
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/arm/omap/crossbar.txt
This is a TI specifi
On 04.07.2019 20:38, Andrew Cooper wrote:
> On 04/07/2019 15:54, Jan Beulich wrote:
>> On 04.07.2019 16:47, Andrew Cooper wrote:
>>> On 01/07/2019 12:22, Jan Beulich wrote:
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -268,7 +268,7 @@ def crunch_numbers(state):
On 04.07.2019 18:11, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 04 July 2019 16:49
>> To: Anthony Perard
>> Cc: xen-devel@lists.xenproject.org; Paul Durrant ;
>> Konrad Rzeszutek Wilk
>> ; Juergen Gross
>> Subject: Re: [Xen-devel] [PATCH] include/public/io/r
Hi All,
Thank you very much for all the code and configuration information
provided. Finally, it was possible to check the next patches with rcar
sk rev3 + kf board. Please be aware that the patches has been
additionally checked with dom0less setup (native xen with dom0 had
been tested previously
On 03.07.19 14:21, Andrew Cooper wrote:
On 03/07/2019 07:30, Juergen Gross wrote:
On 02.07.19 18:09, Andrew Cooper wrote:
On 28/05/2019 11:32, Juergen Gross wrote:
Instead of dynamically decide whether the previous vcpu was using full
"deciding"
or default GDT just add a percpu variable fo
63 matches
Mail list logo
