flight 164205 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164205/
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 164203 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164203/
Regressions :-(
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-credit1
flight 164221 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164221/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164206
Tests which
> From: Kevin Stefanov
> Sent: Monday, August 16, 2021 8:43 PM
>
> Also fix stray usage in VT-d.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Kevin Stefanov
Reviewed-by: Kevin Tian
> ---
> CC: Jan Beulich
> CC: Andrew Cooper
> CC: "Roger Pau Monné"
> CC: Wei Liu
> CC: Kevin Tian
>
> From: Jan Beulich
> Sent: Tuesday, August 3, 2021 7:14 PM
>
> While for 5500 and 5520 chipsets only B3 and C2 are mentioned in the
> spec update, X58's also mentions B2, and searching the internet suggests
> systems with this stepping are actually in use. Even worse, for X58
> erratum #69 is ma
> -Original Message-
> From: Julien Grall
> Sent: Tuesday, August 17, 2021 1:55 AM
> To: Penny Zheng ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Wei Chen
> ; nd
> Subject: Re: [PATCH V4 10/10] xen/arm: introduce allocate_static_memory
>
>
>
> O
> -Original Message-
> From: Julien Grall
> Sent: Tuesday, August 17, 2021 1:44 AM
> To: Penny Zheng ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Wei Chen
> ; nd
> Subject: Re: [PATCH V4 08/10] xen/arm: introduce acquire_staticmem_pages
> and acqui
Hi Julien
> -Original Message-
> From: Julien Grall
> Sent: Tuesday, August 17, 2021 1:28 AM
> To: Penny Zheng ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Wei Chen
> ; nd
> Subject: Re: [PATCH V4 01/10] xen/arm: introduce domain on Static Allocatio
Hi,
I've got another S3 issue:
(XEN) Preparing system for ACPI S3 state.
(XEN) Disabling non-boot CPUs ...
(XEN) Broke affinity for IRQ1, new:
(XEN) Broke affinity for IRQ16, new:
(XEN) Broke affinity for IRQ9, new:
(XEN) Broke affinity for IRQ139, new:
(XEN) Broke affinity fo
flight 164211 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164211/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164206
Tests which
On Mon, Aug 16, 2021 at 02:18:33PM +0200, Jan Beulich wrote:
> On 16.08.2021 12:25, Marek Marczykowski-Górecki wrote:
> > On Mon, Aug 16, 2021 at 11:18:31AM +0200, Jan Beulich wrote:
> >> Hard to tell without knowing whether the extra reg - as per the spec -
> >> is connected to any of these. Is th
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree
flight 164202 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164202/
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
Tests which are fail
flight 164199 qemu-mainline real [real]
flight 164208 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164199/
http://logs.test-lab.xenproject.org/osstest/logs/164208/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 164207 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164207/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164206
Tests which
On 16/08/2021 16:29, Jan Beulich wrote:
> About every time I look at dom0_construct_pv()'s "calculation" of
> nr_pt_pages I question (myself) whether the result is precise or merely
> an upper bound. I think it is meant to be precise, but I think we would
> be better off having some checking in pla
On 16/08/2021 16:31, Jan Beulich wrote:
> While already the case for PVH, there's no reason to treat PV
> differently here (except of course where to take the addresses from).
>
> Signed-off-by: Jan Beulich
Honestly, this is already a mess but I think the change is making things
worse rather than
On 16/08/2021 08:51, Penny Zheng wrote:
+ d, bank, pbase, pbase + psize);
+
+/*
+ * It shall be mapped to the fixed guest RAM address rambase[i],
+ * And until it exhausts the ramsize[i], it will seek to the next
+ * rambase[i+1].
+ */
+
On 16/08/2021 07:43, Penny Zheng wrote:
Hi Julien,
Hi,
+{
+bool need_tlbflush = false;
+uint32_t tlbflush_timestamp = 0;
+unsigned long i;
+struct page_info *pg;
+
+/* For now, it only supports pre-configured static memory. */
This comment doesn't seem to match the ch
On 16/08/2021 07:00, Penny Zheng wrote:
Hi Julien
Hi Penny,
-Original Message-
From: Julien Grall
Sent: Wednesday, August 11, 2021 9:48 PM
To: Penny Zheng ; xen-devel@lists.xenproject.org;
sstabell...@kernel.org
Cc: Bertrand Marquis ; Wei Chen
; nd
Subject: Re: [PATCH V4 03/10] x
From: Tianyu Lan Sent: Monday, August 9, 2021 10:56 AM
>
> VMbus ring buffer are shared with host and it's need to
s/it's need/it needs/
> be accessed via extra address space of Isolation VM with
> SNP support. This patch is to map the ring buffer
> address in extra address space via ioremap().
On 16/08/2021 06:21, Penny Zheng wrote:
Hi Julien
Hi Penny,
-Original Message-
From: Julien Grall
Sent: Wednesday, August 11, 2021 9:32 PM
To: Penny Zheng ; xen-devel@lists.xenproject.org;
sstabell...@kernel.org
Cc: Bertrand Marquis ; Wei Chen
; nd
Subject: Re: [PATCH V4 01/10] x
flight 164206 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164206/
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 10/08/2021 14:37, Jan Beulich wrote:
Hello,
while I don't expect this case to occur often in practice, for
superpage support we will need to be able to correctly free a
page table (hierarchy) after replacing its mapping range by a
superpage. Following P2M by carrying out an immediate iotlb fl
On 16/08/2021 16:30, Jan Beulich wrote:
> Especially with XEN_GUEST, being a prereq of PV_SHIM, defaulting to N,
> v{xenstore,console}_{start,end} can only ever be zero in such default
> configurations. And in case video is the only output configured, space
> is scarce. Omit the two lines carrying
On 10.08.2021 10:50, Jan Beulich wrote:
> On 10.08.2021 10:33, Andrew Cooper wrote:
>> On 03/08/2021 07:37, Jan Beulich wrote:
>>> On 27.07.2021 14:33, Andrew Cooper wrote:
On 22/07/2021 10:20, Jan Beulich wrote:
> I suspect it is commit 40726f16a8d7 ("ld script expression parsing")
>
While already the case for PVH, there's no reason to treat PV
differently here (except of course where to take the addresses from).
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -199,9 +199,18 @@ static bool __hwdom_init hwdom_i
Especially with XEN_GUEST, being a prereq of PV_SHIM, defaulting to N,
v{xenstore,console}_{start,end} can only ever be zero in such default
configurations. And in case video is the only output configured, space
is scarce. Omit the two lines carrying no information at all in this
case.
Signed-off-
About every time I look at dom0_construct_pv()'s "calculation" of
nr_pt_pages I question (myself) whether the result is precise or merely
an upper bound. I think it is meant to be precise, but I think we would
be better off having some checking in place. Hence add ASSERT()s to
verify that
- all pag
From: Tianyu Lan Sent: Monday, August 9, 2021 10:56 AM
>
> Hyper-V provides two kinds of Isolation VMs. VBS(Virtualization-based
> security) and AMD SEV-SNP unenlightened Isolation VMs. This patchset
> is to add support for these Isolation VM support in Linux.
>
A general comment about this ser
On 8/14/2021 1:58 AM, Tianyu Lan wrote:
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 PA
On 16/08/2021 14:58, Jan Beulich wrote:
> On 16.08.2021 15:35, Andrew Cooper wrote:
>> Booting Xen as a PVH guest currently yields:
>>
>> (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:b004,1:0], pm1x_evt[1:b000,1:0]
>> (XEN) ACPI: FACS is not 64-byte aligned: 0xfc001010<2>ACPI:
>> wakeup_vec[fc00101c], v
On 16.08.2021 15:58, Jan Beulich wrote:
> On 16.08.2021 15:35, Andrew Cooper wrote:
>> Booting Xen as a PVH guest currently yields:
>>
>> (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:b004,1:0], pm1x_evt[1:b000,1:0]
>> (XEN) ACPI: FACS is not 64-byte aligned: 0xfc001010<2>ACPI:
>> wakeup_vec[fc00101c], v
On 16.08.2021 15:35, Andrew Cooper wrote:
> Booting Xen as a PVH guest currently yields:
>
> (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:b004,1:0], pm1x_evt[1:b000,1:0]
> (XEN) ACPI: FACS is not 64-byte aligned: 0xfc001010<2>ACPI:
> wakeup_vec[fc00101c], vec_size[20]
> (XEN) ACPI: Local APIC address
Booting Xen as a PVH guest currently yields:
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:b004,1:0], pm1x_evt[1:b000,1:0]
(XEN) ACPI: FACS is not 64-byte aligned: 0xfc001010<2>ACPI:
wakeup_vec[fc00101c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee0
Insert newlines as appropriate.
Fixes: d
On 16.08.2021 14:42, Kevin Stefanov wrote:
> Also fix stray usage in VT-d.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Kevin Stefanov
Reviewed-by: Jan Beulich
On 16.08.2021 07:25, Juergen Gross wrote:
> On 03.08.21 12:42, Jan Beulich wrote:
>> On 30.07.2021 11:00, Juergen Gross wrote:
>>> On 16.06.21 12:43, Juergen Gross wrote:
On 16.06.21 11:56, Jan Beulich wrote:
> On 16.06.2021 09:30, Juergen Gross wrote:
>> --- a/arch/x86/xen/p2m.c
>
Also fix stray usage in VT-d.
Suggested-by: Andrew Cooper
Signed-off-by: Kevin Stefanov
---
CC: Jan Beulich
CC: Andrew Cooper
CC: "Roger Pau Monné"
CC: Wei Liu
CC: Kevin Tian
v2:
* Also replace literal 1/0
v3:
* Fix 1->false conversion error
---
xen/arch/x86/io_apic.c |
flight 164197 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164197/
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
On 16.08.2021 12:25, Marek Marczykowski-Górecki wrote:
> On Mon, Aug 16, 2021 at 11:18:31AM +0200, Jan Beulich wrote:
>> On 16.08.2021 10:39, Marek Marczykowski-Górecki wrote:
>>> On Mon, Aug 16, 2021 at 09:55:16AM +0200, Jan Beulich wrote:
On 13.08.2021 20:31, Marek Marczykowski-Górecki wrote
flight 164201 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164201/
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
On 16.08.2021 13:19, 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 Mon, Aug 16, 2021 at 01:09:52PM +0200, Juergen Gross wrote:
> Greg,
>
> could you please add upstream commit 05d69d950d9d8 ("xen-blkfront:
> sanitize the removal state machine") to the stable 5.13 kernel?
>
> The patch seems not to have a "Cc: stable" tag while it fixes an
> issue introduced i
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
Jane Malalane (2):
x86/pv: remove unnecessary use of goto out in construct_dom0()
x86/pv: Provide more helpful error when CONFIG_PV32 is absent
xen/arch/x86/pv/dom0_build.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
--
2.11.0
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
Reviewed-by: Jan Beulich
---
CC: Jan Beulich
CC: Andrew Cooper
CC: "Roger Pau Monné"
CC: Wei Liu
v2:
* add into series
* fixup ordering er
Greg,
could you please add upstream commit 05d69d950d9d8 ("xen-blkfront:
sanitize the removal state machine") to the stable 5.13 kernel?
The patch seems not to have a "Cc: stable" tag while it fixes an
issue introduced in 5.13.
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP publ
flight 164196 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164196/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
test-armhf-armhf-xl
On 13/08/2021 15:00, Jan Beulich wrote:
> 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
On Mon, Aug 16, 2021 at 11:18:31AM +0200, Jan Beulich wrote:
> On 16.08.2021 10:39, Marek Marczykowski-Górecki wrote:
> > On Mon, Aug 16, 2021 at 09:55:16AM +0200, Jan Beulich wrote:
> >> On 13.08.2021 20:31, Marek Marczykowski-Górecki wrote:
> >>> Besides standard UART setup, this device needs ena
Hi All,
Thanks for Stefano to link my kvmtool for Xen proposal here.
This proposal is still discussing in Xen and KVM communities.
The main work is to decouple the kvmtool from KVM and make
other hypervisors can reuse the virtual device implementations.
In this case, we need to introduce an inter
On 16.08.2021 10:39, Marek Marczykowski-Górecki wrote:
> On Mon, Aug 16, 2021 at 09:55:16AM +0200, Jan Beulich wrote:
>> On 13.08.2021 20:31, Marek Marczykowski-Górecki wrote:
>>> Besides standard UART setup, this device needs enabling
>>> (vendor-specific) "Enhanced Control Bits" - otherwise disab
On Mon, Aug 16, 2021 at 09:55:16AM +0200, Jan Beulich wrote:
> On 13.08.2021 20:31, Marek Marczykowski-Górecki wrote:
> > Besides standard UART setup, this device needs enabling
> > (vendor-specific) "Enhanced Control Bits" - otherwise disabling hardware
> > control flow (MCR[2]) is ignored. Add ap
I top post as I find it difficult to identify where to make the comments.
1) BE acceleration
Network and storage backends may actually be executed in SmartNICs. As
virtio 1.1 is hardware friendly, there may be SmartNICs with virtio 1.1 PCI
VFs. Is it a valid use case for the generic BE framework t
On 13.08.2021 20:31, Marek Marczykowski-Górecki wrote:
> 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 handl
Hi julien
> -Original Message-
> From: Julien Grall
> Sent: Friday, August 13, 2021 9:37 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Wei Chen
> ; nd
> Subject: Re: [PATCH V4 10/10] xen/arm: introduce allocate_static_memory
>
>
On 13.08.2021 20:31, Marek Marczykowski-Górecki wrote:
> 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
Reviewed-by: Jan Beulich
On 14.08.2021 01:28, Oleksandr Tyshchenko wrote:
> 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
On 16.08.2021 07:50, osstest service owner wrote:
> flight 164195 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/164195/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-armhf-
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月13日 20:38
> To: Penny Zheng ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Wei Chen
> ; nd
> Subject: Re: [PATCH V4 05/10] xen/arm: static memory initialization
>
> Hi Penny,
>
> On
60 matches
Mail list logo
