flight 164181 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164181/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
test-armhf-armhf-examine 5 host-insta
flight 164180 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164180/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
test-armhf-armhf-xl-arn
flight 164178 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164178/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
Tests which are fail
On 05.08.21 20:25, Julien Grall wrote:
Hi Oleksandr,
Hi Julien, all
On 05/08/2021 15:52, Oleksandr wrote:
On 05.08.21 01:00, Julien Grall wrote:
On 04/08/2021 21:56, Oleksandr wrote:
Hi Julien, Stefano.
Hi Oleksandr,
Hi, Julien
Thank you for the prompt reply and explanation
From: Oleksandr Tyshchenko
We need to pass info about maximum supported address space size
to the toolstack on Arm in order to properly calculate the base
and size of the safe range for the guest. Use p2m_ipa_bits variable
which purpose is to hold the bit size of IPAs in P2M tables.
As we change
On 09.08.21 17:51, Julien Grall wrote:
Hi,
Hi Julien, all
I am writing down here what we discussed on another thread and on IRC.
This will be easier to track in a single thread.
On 04/08/2021 23:00, Julien Grall wrote:
On 04/08/2021 21:56, Oleksandr wrote:
Now, I am wondering, would i
From: Tianyu Lan Sent: Monday, August 9, 2021 10:56 AM
>
> The monitor pages in the CHANNELMSG_INITIATE_CONTACT msg are shared
> with host in Isolation VM and so it's necessary to use hvcall to set
> them visible to host. In Isolation VM with AMD SEV SNP, the access
> address should be in the ext
From: Oleksandr Tyshchenko
Introduce new gnttab_clean_frame_gfn() which purpose is to
locate a GFN corresponding to the passed MFN and remove it
from the gnttab database. This manual updating is only needed
on arch without M2P support.
So, call it from p2m_put_l3_page() on Arm after making sure
t
From: Tianyu Lan Sent: Monday, August 9, 2021 10:56 AM
>
> Hyper-V provides ghcb hvcall to handle VMBus
> HVCALL_SIGNAL_EVENT and HVCALL_POST_MESSAGE
> msg in SNP Isolation VM. Add such support.
>
> Signed-off-by: Tianyu Lan
> ---
> arch/x86/hyperv/ivm.c | 43
From: Michael Kelley Sent: Friday, August 13, 2021
12:31 PM
> To: Tianyu Lan ; KY Srinivasan ;
> Haiyang Zhang ;
> Stephen Hemminger ; wei@kernel.org; Dexuan Cui
> ;
> t...@linutronix.de; mi...@redhat.com; b...@alien8.de; x...@kernel.org;
> h...@zytor.com; dave.han...@linux.intel.com;
> l.
From: Tianyu Lan Sent: Monday, August 9, 2021 10:56 AM
> Subject: [PATCH V3 05/13] HV: Add Write/Read MSR registers via ghcb page
See previous comments about tag in the Subject line.
> Hyper-V provides GHCB protocol to write Synthetic Interrupt
> Controller MSR registers in Isolation VM with AMD
If fifo size is already set via uart_params, do not force it to 16 - which
may not match the actual hardware. Specifically Exar cards have fifo of
256 bytes.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/char/ns16550.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --g
Besides standard UART setup, this device needs enabling
(vendor-specific) "Enhanced Control Bits" - otherwise disabling hardware
control flow (MCR[2]) is ignored. Add appropriate quirk to the
ns16550_setup_preirq(), similar to the handle_dw_usr_busy_quirk(). The
new function act on Exar cards only
flight 164179 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164179/
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 8/12/2021 8:27 PM, Christoph Hellwig wrote:
This is still broken. You need to make sure the actual DMA allocations
do have struct page backing.
Hi Christoph:
swiotlb_tbl_map_single() still returns PA below vTOM/share_gpa_
boundary. These PAs has backing pages and belong to system memo
flight 164177 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164177/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
test-armhf-armhf-examine 5 host-insta
Hi Christoph:
I followed your this suggestion to rework the latest
version(https://lkml.org/lkml/2021/8/9/805). I just remove the arch
prefix from your suggested name arch_dma_map_decrypted because the
platform may populate their map/umap callback in the ops. But from your
latest comment(h
>> But I think, we cannot use64af97000 address in the swiotlb_bounce()
>> directly.
>>
>I am not sure to understand what you mean. Can you clarify?
I thought, that the address 64af97000 can be used directly here:
https://elixir.bootlin.com/linux/v5.10/source/kernel/dma/swiotlb.c#L572
and I was co
Hi Michael:
Thanks for your review.
On 8/13/2021 3:14 AM, Michael Kelley wrote:
From: Tianyu Lan Sent: Monday, August 9, 2021 10:56 AM
Subject: [PATCH V3 01/13] x86/HV: Initialize GHCB page in Isolation VM
The subject line tag on patches under arch/x86/hyperv is generally
"x86/hyperv:"
flight 164174 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164174/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale broken
test-armhf-armhf-xl-rtd
On 13.08.2021 13:02, Jane Malalane wrote:
> --- a/xen/arch/x86/pv/dom0_build.c
> +++ b/xen/arch/x86/pv/dom0_build.c
> @@ -379,8 +379,7 @@ int __init dom0_construct_pv(struct domain *d,
> }
> #else
> printk("Found 32-bit PV kernel, but CONFIG_PV32 missing\n");
> -rc = -ENO
On 12.08.2021 19:03, Andrew Cooper wrote:
> This was a clear oversight in the original CET work. The BUGFRAME_run_fn and
> BUGFRAME_warn paths update regs->rip without an equivlenet adjustment to the
> shadow stack, causes IRET to suffer #CP due to the mismatch.
>
> One subtle, and therefore frag
Hi Penny,
On 28/07/2021 11:27, Penny Zheng wrote:
This commit introduces allocate_static_memory to allocate static memory as
guest RAM for Domain on Static Allocation.
It uses acquire_domstatic_pages to acquire pre-configured static memory
for this domain, and uses guest_physmap_add_page to set
Hi,
On 28/07/2021 11:27, Penny Zheng wrote:
This commit checks "xen,static-mem" device tree property in /domUx node,
to determine whether domain is on Static Allocation, when constructing
domain during boot-up.
Right now, the implementation of allocate_static_memory is missing, and
will be intr
Hi Penny,
On 28/07/2021 11:27, Penny Zheng wrote:
alloc_staticmem_pages aims to acquire nr_mfns contiguous pages of
static memory. And it is the equivalent of alloc_heap_pages for static
memory. Here only covers acquiring pre-configured static memory.
For each page, it shall check if the page i
Hi Penny,
On 28/07/2021 11:27, Penny Zheng wrote:
+/* Static memory initialization */
+static void __init init_staticmem_pages(void)
+{
+unsigned int bank;
+
+/* TODO: Considering NUMA-support scenario. */
I forgot to ask about this. What do you expect to be different with NUMA?
+
On 13.08.2021 13:09, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH] tests/xenstore: link in librt"):
>> On 12.08.2021 13:24, Ian Jackson wrote:
+LDFLAGS += -lrt
>>>
>>> Don't this unconditionally is definitely not right.
>>
>> Assuming you meant "Doing this ..." - why? If the concern is
On 13.08.2021 14:27, Julien Grall wrote:
> On 28/07/2021 11:27, Penny Zheng wrote:
>> --- a/xen/include/xen/mm.h
>> +++ b/xen/include/xen/mm.h
>> @@ -132,6 +132,12 @@ int query_page_offline(mfn_t mfn, uint32_t *status);
>> void heap_init_late(void);
>>
>> int assign_pages(
>> +struct pag
Hi Penny,
On 28/07/2021 11:27, Penny Zheng wrote:
In order to deal with the trouble of count-to-order conversion when page number
is not in a power-of-two, this commit re-define assign_pages for nr pages and
assign_page for original page with a single order.
Backporting confusion could be helpe
Hi Penny,
On 28/07/2021 11:27, Penny Zheng wrote:
This patch introduces a new page flag PGC_reserved in order to differentiate
pages of static memory from those allocated from heap.
Mark pages of static memory PGC_reserved when initializing them.
Signed-off-by: Penny Zheng
I think this want
Hi Penny,
On 28/07/2021 11:27, Penny Zheng wrote:
This patch introduces static memory initialization, during system boot up.
The new function init_staticmem_pages is responsible for static memory
initialization.
Helper free_staticmem_pages is the equivalent of free_heap_pages, to free
nr_mfns
The current policy for minimum supported versions of tools, compilers,
etc. is unsatisfactory: For many dependencies no minimum version is
specified. For those where a version is stated, updating it is a
decision that has to be explicitly taken for that tool.
The result is persistent debates over
Jan Beulich writes ("Re: [PATCH] tests/xenstore: link in librt"):
> On 12.08.2021 13:24, Ian Jackson wrote:
> >> +LDFLAGS += -lrt
> >
> > Don't this unconditionally is definitely not right.
>
> Assuming you meant "Doing this ..." - why? If the concern is that
> librt.so may needlessly get recorde
elf_check_broken() only needs to be invoked after elf_xen_parse() and
after elf_load_binary().
Suggested-by: Jan Beulich
Signed-off-by: Jane Malalane
---
CC: Jan Beulich
CC: Andrew Cooper
CC: "Roger Pau Monné"
CC: Wei Liu
---
xen/arch/x86/pv/dom0_build.c | 15 +--
1 file changed
On 13/08/2021 11:40, Jane Malalane wrote:
Currently, when booting a 32bit dom0 kernel, the message isn't very
helpful:
(XEN) Xen kernel: 64-bit, lsb
(XEN) Dom0 kernel: 32-bit, PAE, lsb, paddr 0x10 -> 0x112000
(XEN) Mismatch between Xen and DOM0 kernel
(XEN)
(XEN) **
On 13/08/2021 10:38, Roman Skakun wrote:
Hi Julien,
Hi Roman,
So 0xb600 is most likely the GFN used to mapped the grant from the domU.
swiotlb-xen on Arm will convert it to the MFN because it is not aware
whether the device is behind an IOMMU.
If I'm understand right, it seems like
flight 164171 xen-unstable real [real]
flight 164176 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164171/
http://logs.test-lab.xenproject.org/osstest/logs/164176/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
Currently, when booting a 32bit dom0 kernel, the message isn't very
helpful:
(XEN) Xen kernel: 64-bit, lsb
(XEN) Dom0 kernel: 32-bit, PAE, lsb, paddr 0x10 -> 0x112000
(XEN) Mismatch between Xen and DOM0 kernel
(XEN)
(XEN)
(XEN) Panic on C
flight 164172 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164172/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
test-armhf-armhf-examine 5 host-insta
flight 164175 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164175/
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-arm64-libvirt
Hi Julien,
> So 0xb600 is most likely the GFN used to mapped the grant from the domU.
>
> swiotlb-xen on Arm will convert it to the MFN because it is not aware
> whether the device is behind an IOMMU.
If I'm understand right, it seems like that swiotlb-xen is not ready to work
properly in ca
On 19.07.2021 09:46, Jan Beulich wrote:
> On 05.07.2021 17:09, Jan Beulich wrote:
>> ... or so I hope. This series continues the attempt to deal with
>> the ovmf change putting the shared info page at a very high address
>> (which is now planned to get reverted there, but the general
>> problem doe
flight 164173 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164173/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6fdd1c13a734609aff68d37e606e995d673d9aeb
baseline version:
ovmf ac826886c98524e918753
On 13.08.2021 09:26, Wei Chen wrote:
>> From: Jan Beulich
>> Sent: 2021年8月12日 23:33
>>
>> On 11.08.2021 12:23, Wei Chen wrote:
>>> --- a/xen/arch/x86/numa.c
>>> +++ b/xen/arch/x86/numa.c
>>> @@ -270,6 +270,8 @@ void __init numa_initmem_init(unsigned long
>> start_pfn, unsigned long end_pfn)
>>>
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月13日 0:55
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jbeul...@suse.com
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 06/40] xen: decouple NUMA from ACPI in Kconfig
>
> Hi Wei,
>
>
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2021年8月12日 23:37
> To: Wei Chen
> Cc: Bertrand Marquis ; xen-
> de...@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org
> Subject: Re: [XEN RFC PATCH 06/40] xen: decouple NUMA from ACPI in Kconfig
>
> On 11.08.2021 12:2
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2021年8月12日 23:33
> To: Wei Chen
> Cc: Bertrand Marquis ; xen-
> de...@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org
> Subject: Re: [XEN RFC PATCH 03/40] xen/x86: Initialize memnodemapsize
> while faking NUMA node
>
47 matches
Mail list logo
