Good day,
You're looking for this document i was focusing on a week ago, i believe. Anyway, here's the url to this doc below:
https://tutiendafit.com.mx/olea/sndaem
On 3/15/22 7:38 AM, Jan Beulich wrote:
> On 14.03.2022 04:41, Chuck Zmudzinski wrote:
>> Fixes: abfb006f1ff4 (tools/libxl:
flight 169530 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169530/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Mon, Apr 18, 2022 at 6:53 AM Christoph Hellwig wrote:
>
> Use bdev_discard_alignment to calculate the correct discard alignment
> offset even for partitions instead of just looking at the queue limit.
>
> Signed-off-by: Christoph Hellwig
Thx!
Acked-by: Jack Wang
> ---
>
flight 169529 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169529/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
From: Peng Fan
The i.MX LPUART Documentation:
https://www.nxp.com/webapp/Download?colCode=IMX8QMIEC
Chatper 13.6 Low Power Universal Asynchronous Receiver/
Transmitter (LPUART)
Tested-by: Henry Wang
Signed-off-by: Peng Fan
---
xen/arch/arm/include/asm/imx-lpuart.h | 64 ++
From: Peng Fan
Signed-off-by: Peng Fan
---
xen/arch/arm/Kconfig.debug | 14
xen/arch/arm/arm64/debug-imx-lpuart.inc | 48 +
2 files changed, 62 insertions(+)
create mode 100644 xen/arch/arm/arm64/debug-imx-lpuart.inc
diff --git
From: Peng Fan
V6:
Fix a stale variable check per Stefano's comments.
V5:
Align code
drop early_uart_init
V4:
Wrong v3 version, some BIT definition are mixed in patch 1,2.
V3:
Addressed Michal's comments.
Add Henry's T-b
V2:
Per Julien's comments, fix coding style issue, drop
flight 169527 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169527/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Sent: 2022年4月15日 8:41
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; jul...@xen.org; Stefano Stabellini
> ; Bertrand Marquis ;
> Penny Zheng
> Subject: Re: Proposal for Porting Xen to Armv8-R64 - DraftB
>
> On Fri, 25
flight 169526 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169526/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
+rust-...@lists.opendev.org
On Thu, 14 Apr 2022 at 14:54, Viresh Kumar wrote:
>
> +xen-devel
>
> On 14-04-22, 14:45, Viresh Kumar wrote:
> > Hello,
> >
> > We verified our hypervisor-agnostic Rust based vhost-user backends with Qemu
> > based setup earlier, and there was growing concern if they
flight 169525 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169525/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169524 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169524/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
Hi,
Sorry for the formatting issues.
On Mon, 18 Apr 2022, 21:41 Stefano Stabellini,
wrote:
> > +static uint64_t virtio_mmio_base;
> > +static uint32_t virtio_mmio_irq;
>
> No need for these two variables to be global in this file, they could be
> local variables in
flight 169523 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169523/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This is needed for grant table based DMA ops layer (CONFIG_XEN_VIRTIO)
> at the guest side to retrieve the ID of Xen domain where the corresponding
> backend resides (it is used as an argument to the grant table
On Fri, 8 Apr 2022, Oleksandr Tyshchenko wrote:
> From: Julien Grall
>
> This patch introduces helpers to allocate Virtio MMIO params
> (IRQ and memory region) and create specific device node in
> the Guest device-tree with allocated params. In order to deal
> with multiple Virtio devices,
> From: Oleksandr Tyshchenko
>
> This patch adds basic support for configuring and assisting virtio-mmio
> based virtio-disk backend (emualator) which is intended to run out of
^ emulator
On Wed, Apr 06, 2022 at 12:10:17PM +0200, Jan Beulich wrote:
> On 02.04.2022 01:14, Demi Marie Obenour wrote:
> > The EFI System Resource Table (ESRT) is necessary for fwupd to identify
> > firmware updates to install. According to the UEFI specification §23.4,
> > the table shall be stored in
flight 169522 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169522/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 4/17/22 21:53, Christoph Hellwig wrote:
> The nvme driver never sets a discard_alignment, so it also doens't need
> to clear it to zero.
>
> Signed-off-by: Christoph Hellwig
> ---
Reviewed-by: Chaitanya Kulkarni
-ck
On 4/17/22 21:53, Christoph Hellwig wrote:
> The discard_alignment queue limit is named a bit misleading means the
> offset into the block device at which the discard granularity starts.
> Setting it to the discard granularity as done by null_blk is mostly
> harmless but also useless.
>
>
On 4/17/22 21:53, Christoph Hellwig wrote:
> The loop driver never sets a discard_alignment, so it also doens't need
s/doens't/doesn't/
> to clear it to zero.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Chaitanya Kulkarni
-ck
On Fri, 1 Apr 2022, Julien Grall wrote:
> On 24/03/2022 13:37, Ayan Kumar Halder wrote:
> > /*
> >* At this point, we know that the instruction is either valid or has
> > been
> >* decoded successfully. Thus, Xen should be allowed to execute the
> > diff --git
flight 169521 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169521/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Sun, 17 Apr 2022, Rahul Singh wrote:
> > On 15 Apr 2022, at 6:40 pm, Stefano Stabellini
> > wrote:
> > On Fri, 15 Apr 2022, Christoph Hellwig wrote:
> >> On Thu, Apr 14, 2022 at 01:39:23PM -0700, Stefano Stabellini wrote:
> >>> OK, now we know that the code path with Xen is correct and it is
flight 169520 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169520/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169519 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169519/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Sun, 17 Apr 2022, Oleksandr wrote:
> On 16.04.22 01:02, Stefano Stabellini wrote:
> > On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
> > > From: Oleksandr Tyshchenko
> > >
> > > In the context of current patch do the following:
> > > 1. Update code to support virtio-mmio devices
> > > 2.
On Mon, 18 Apr 2022, Oleksandr wrote:
> On 16.04.22 09:07, Christoph Hellwig wrote:
>
> Hello Christoph
>
> > On Fri, Apr 15, 2022 at 03:02:45PM -0700, Stefano Stabellini wrote:
> > > This makes sense overall. Considering that the swiotlb-xen case and the
> > > virtio case are mutually
On Sun, 17 Apr 2022, Oleksandr wrote:
> On 16.04.22 01:01, Stefano Stabellini wrote:
> > On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
> > > From: Juergen Gross
> > >
> > > In order to support virtio in Xen guests add a config option enabling
> > > the user to specify whether in all Xen
On Fri, Mar 25, 2022 at 9:34 AM Tamas K Lengyel wrote:
>
> During VM forking and resetting a failed vmentry has been observed due
> to the guest non-register state going out-of-sync with the guest register
> state. For example, a VM fork reset right after a STI instruction can trigger
> the
flight 169518 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169518/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169517 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169517/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169516 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169516/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
The startup_xen() kernel entry point is referenced by the ".note.Xen"
section, but is presumably not indirect-branched to. Add ANNOTATE_ENDBR
to silence future objtool warnings.
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Josh
flight 169515 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169515/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169514 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169514/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169513 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169513/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169512 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169512/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169511 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169511/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Fri, 15 Apr 2022 06:52:31 +0200, Christoph Hellwig wrote:
> this series cleanups up the block layer API so that APIs consumed
> by file systems are (almost) only struct block_devic based, so that
> file systems don't have to poke into block layer internals like the
> request_queue.
>
> I also
flight 169510 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169510/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
When static domain populates memory through populate_physmap on runtime,
other than allocating from heap, it shall retrieve reserved pages from
resv_page_list to make sure that guest RAM is still restricted in statically
configured memory regions. And this commit introduces a new helper
In order to have an easy and quick way to find out whether this domain memory
is statically configured, this commit introduces a new flag CDF_staticmem and a
new helper is_domain_static to tell.
Signed-off-by: Penny Zheng
---
v2 changes:
- change name from "is_domain_on_static_allocation" to
With more and more CDF_xxx internal flags in and to save the space, this
commit introduces a new field "flags" in struct domain to store CDF_*
internal flags directly.
Another new CDF_xxx will be introduced in the next patch.
Signed-off-by: Penny Zheng
---
v2 changes:
- let "flags" live in the
Today when a domain unpopulates the memory on runtime, they will always
hand the memory back to the heap allocator. And it will be a problem if domain
is static.
Pages as guest RAM for static domain shall be reserved to only this domain
and not be used for any other purposes, so they shall never
There is a slim chance that free_heap_pages() may decide to merge a chunk
from the static region(PGC_reserved) with the about-to-be-free chunk.
So in order to avoid the above scenario, this commit updates free_heap_pages()
to check whether the predecessor and/or successor has PGC_reserved set,
Today when a domain unpopulates the memory on runtime, they will always
hand the memory over to the heap allocator. And it will be a problem if it
is a static domain. Pages as guest RAM for static domain shall always be
reserved to only this domain and not be used for any other purposes, so
they
Pages as guest RAM for static domain, shall be reserved to this domain only.
So in case reserved pages being used for other purpose, users
shall not free them back to heap, even when last ref gets dropped.
free_staticmem_pages will be called by free_domheap_pages in runtime
for static domain
flight 169509 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169509/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169495 linux-linus real [real]
flight 169507 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169495/
http://logs.test-lab.xenproject.org/osstest/logs/169507/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
The use of kmap() is being deprecated in favor of kmap_local_page()
where it is feasible.
With kmap_local_page(), the mapping is per thread, CPU local and not
globally visible. Therefore __del_gref() is a function
where the use of kmap_local_page() in place of kmap() is correctly
suited.
flight 169508 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169508/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169499 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169499/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169472
test-amd64-amd64-qemuu-nested-amd
flight 169506 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169506/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
One NUMA node may contain several memory blocks. In current Xen
code, Xen will maintain a node memory range for each node to cover
all its memory blocks. But here comes the problem, in the gap of
one node's two memory blocks, if there are some memory blocks don't
belong to this node (remote memory
VIRTUAL_BUG_ON is an empty macro used in phys_to_nid. This
results in two lines of error-checking code in phys_to_nid
that is not actually working and causing two compilation
errors:
1. error: "MAX_NUMNODES" undeclared (first use in this function).
This is because in the common header file,
We have introduced CONFIG_NUMA in a previous patch. And this
option is enabled only on x86 at the current stage. In a follow
up patch, we will enable this option for Arm. But we still
want users to be able to disable the CONFIG_NUMA via Kconfig. In
this case, keep the fake NUMA API, will make Arm
In current Xen code only implements x86 ACPI-based NUMA support.
So in Xen Kconfig system, NUMA equals to ACPI_NUMA. x86 selects
NUMA by default, and CONFIG_ACPI_NUMA is hardcode in config.h.
In a follow-up patch, we will introduce support for NUMA using
the device tree. That means we will have
In current code, when Xen is booting from EFI, it will delete
all memory nodes in device tree. This would work well in current
stage, because Xen can get memory map from EFI system table.
However, EFI system table cannot completely replace memory nodes
of device tree. EFI system table doesn't
In current code, when Xen is running in a multiple nodes
NUMA system, it will set dma_bitsize in end_boot_allocator
to reserve some low address memory as DMA zone.
There are some x86 implications in the implementation.
Because on x86, memory starts from 0. On a multiple-nodes
NUMA system, if a
x86 is using compiler feature testing to decide EFI
build enable or not. When EFI build is disabled, x86
will use a efi/stub.c file to replace efi/runtime.c
for build objects. Following this idea, we introduce
a stub file for Arm, but use CONFIG_ARM_EFI to decide
EFI build enable or not.
Current putn function that is using for early print
only can print low 32-bit of AArch64 register. This
will lose some important messages while debugging
with early console. For example:
(XEN) Bringing up CPU5
- CPU 00010100 booting -
Will be truncated to
(XEN) Bringing up CPU5
- CPU
Most of the functions in x86 EFI stub.c can be reused for other
architectures. So we move them to common and keep the x86 specific
function in stub-x86.c.
Signed-off-by: Wei Chen
---
v1 -> v2:
1. Drop the copy of stub.c from Arm EFI.
2. Share common codes of x86 EFI stub for other architectures.
(The Arm device tree based NUMA support patch set contains 35
patches. In order to make stuff easier for reviewers, I split
them into 3 parts:
1. Preparation. I have re-sorted the patch series. And moved
independent patches to the head of the series.
2. Move generically usable code from x86 to
flight 169505 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169505/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 169504 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169504/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On 4/18/22 13:53, Christoph Hellwig wrote:
> The loop driver never sets a discard_alignment, so it also doens't need
> to clear it to zero.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/block/loop.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/block/loop.c
On 4/18/22 13:53, Christoph Hellwig wrote:
> Use bdev_discard_alignment to calculate the correct discard alignment
> offset even for partitions instead of just looking at the queue limit.
>
> Also switch to use bdev_discard_granularity to get rid of the last direct
> queue reference in
On 4/18/22 13:53, Christoph Hellwig wrote:
> Use bdev_discard_alignment to calculate the correct discard alignment
> offset even for partitions instead of just looking at the queue limit.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/block/rnbd/rnbd-srv-dev.h | 2 +-
> 1 file changed, 1
On 4/18/22 13:53, Christoph Hellwig wrote:
> The nvme driver never sets a discard_alignment, so it also doens't need
> to clear it to zero.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/nvme/host/core.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/nvme/host/core.c
On 4/18/22 13:53, Christoph Hellwig wrote:
> The discard_alignment queue limit is named a bit misleading means the
> offset into the block device at which the discard granularity starts.
> Setting it to the discard granularity as done by null_blk is mostly
> harmless but also useless.
>
>
On 4/18/22 13:53, Christoph Hellwig wrote:
> The discard_alignment queue limit is named a bit misleading means the
> offset into the block device at which the discard granularity starts.
> Setting it to the discard granularity as done by dm-zoned is mostly
> harmless but also useless.
>
>
flight 169503 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169503/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
On Mon, 18 Apr 2022, Alaa Mohamed wrote:
> The use of kmap() is being deprecated in favor of kmap_local_page()
> where it is feasible.
>
> With kmap_local_page(), the mapping is per thread, CPU local and not
> globally visible. Therefore __del_gref() is a function
> where the use of
flight 169502 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169502/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
77 matches
Mail list logo
