On Tue, Feb 09, 2021 at 03:28:12PM +, Julien Grall wrote:
> From: Julien Grall
>
> Currently, the IOMMU page-tables will be populated early in the domain
> creation if the hardware is able to virtualize the local APIC. However,
> the IOMMU page tables will not be freed during early failure an
On 09.02.2021 18:39, Andrew Cooper wrote:
> On 09/02/2021 17:17, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [PATCH for-4.15] x86/ucode: Fix microcode payload
>> size for Fam19 processors"):
>>> On 09.02.2021 16:33, Andrew Cooper wrote:
The original limit provided wasn't accurate. Blobs a
Hi Roger,
On 10/02/2021 08:29, Roger Pau Monné wrote:
On Tue, Feb 09, 2021 at 03:28:12PM +, Julien Grall wrote:
From: Julien Grall
Currently, the IOMMU page-tables will be populated early in the domain
creation if the hardware is able to virtualize the local APIC. However,
the IOMMU page
On 20.01.21 19:05, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
Sorry for the late response.
On 18/01/2021 08:32, Oleksandr wrote:
On 16.01.21 00:01, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 12/01/2021 21:52, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This
Am Tue, 9 Feb 2021 17:12:28 +
schrieb Ian Jackson :
> It seems to me that something is definitely a bug here but I want to
> understand from Andy what the best thing to do is. I'm hesitant to
> release-ack removing this at this stage.
>
> Wouldn't it be better to just fix the docs like in yo
The for loop in unmap_domain_pirq is unnecessary complicated, with
several places where the index is incremented, and also different
exit conditions spread between the loop body.
Simplify it by looping over each possible PIRQ using the for loop
syntax, and remove all possible in-loop exit points.
On 10/02/2021 08:50, Julien Grall wrote:
Hi Roger,
On 10/02/2021 08:29, Roger Pau Monné wrote:
On Tue, Feb 09, 2021 at 03:28:12PM +, Julien Grall wrote:
From: Julien Grall
Currently, the IOMMU page-tables will be populated early in the domain
creation if the hardware is able to virtualiz
Am Wed, 10 Feb 2021 10:06:06 +0100
schrieb Olaf Hering :
> -if ( ctx->save.debug && ctx->stream_type != XC_STREAM_PLAIN )
> +if ( ctx->save.debug )
This will do the verification, and finds many errors:
2021-02-10 02:37:03 MST [2149] xc: error: verify pfn 0xfda9 failed (type 0):
Internal
flight 159197 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159197/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 687121f8a0e7c1ea1c4fa3d056637e5819342f14
baseline version:
xen 5e7a
When invoked by compat mode, mode_64bit() will be false at the start of
emulation. The logic after complete_insn, however, needs to consider the
mode switched into, in particular to avoid truncating RIP.
Inspired by / paralleling and extending Linux commit 943dea8af21b ("KVM:
x86: Update emulator
On 09.02.2021 22:49, Andrew Cooper wrote:
> Currently, a failure of verify_patch_size() causes an early abort of the
> microcode blob loop, which in turn causes a second go around the main
> container loop, ultimately failing the UCODE_MAGIC check.
>
> First, check for errors after the blob loop.
On 10.02.2021 00:40, Andrew Cooper wrote:
> verify_patch_size() is a maximum size check, and doesn't have a minimum bound.
>
> If the microcode container encodes a blob with a length less than 64 bytes,
> the subsequent calls to microcode_fits()/compare_header() may read off the end
> of the buffe
> On Feb 9, 2021, at 5:31 PM, Stefano Stabellini wrote:
>
> On Tue, 9 Feb 2021, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [PATCH v2] xen/arm: fix gnttab_need_iommu_mapping"):
>>> On 08.02.2021 21:24, Stefano Stabellini wrote:
>> ...
For these cases, I would just follow a simple rule o
On 10.02.2021 09:29, Roger Pau Monné wrote:
> On Tue, Feb 09, 2021 at 03:28:12PM +, Julien Grall wrote:
>> From: Julien Grall
>>
>> Currently, the IOMMU page-tables will be populated early in the domain
>> creation if the hardware is able to virtualize the local APIC. However,
>> the IOMMU pag
flight 159181 linux-linus running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159181/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 10 host-ping-check-xen fail REGR. vs. 152332
test-arm64-arm64
flight 159166 linux-5.4 running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159166/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 14 guest-start fail REGR. vs. 158387
test-arm64-arm64-x
flight 159187 xen-4.12-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159187/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit1 broken in 159052
test-amd64-amd64-pair
flight 159156 xen-unstable running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159156/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 broken
test-amd64-amd64-xl-qemut-debi
flight 159195 libvirt running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159195/
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
flight 159176 qemu-mainline running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159176/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 12 debian-di-installfail REGR. vs. 152631
test-armhf-arm
On 09.02.2021 16:28, Julien Grall wrote:
> From: Julien Grall
>
> Currently, the IOMMU page-tables will be populated early in the domain
> creation if the hardware is able to virtualize the local APIC. However,
> the IOMMU page tables will not be freed during early failure and will
> result to a
flight 159194 xen-4.11-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159194/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm queued
test-
On Wed, Feb 10, 2021 at 12:10:09PM +0100, Jan Beulich wrote:
> On 10.02.2021 09:29, Roger Pau Monné wrote:
> > On Tue, Feb 09, 2021 at 03:28:12PM +, Julien Grall wrote:
> >> From: Julien Grall
> >>
> >> Currently, the IOMMU page-tables will be populated early in the domain
> >> creation if the
On 10.02.2021 12:34, Roger Pau Monné wrote:
> On Wed, Feb 10, 2021 at 12:10:09PM +0100, Jan Beulich wrote:
>> On 10.02.2021 09:29, Roger Pau Monné wrote:
>>> I get the feeling this is just papering over an existing issue instead
>>> of actually fixing it: IOMMU page tables need to be properly freed
On 10/02/2021 11:38, Jan Beulich wrote:
On 10.02.2021 12:34, Roger Pau Monné wrote:
On Wed, Feb 10, 2021 at 12:10:09PM +0100, Jan Beulich wrote:
On 10.02.2021 09:29, Roger Pau Monné wrote:
I get the feeling this is just papering over an existing issue instead
of actually fixing it: IOMMU pa
On 10.02.2021 12:40, Julien Grall wrote:
> On 10/02/2021 11:38, Jan Beulich wrote:
>> On 10.02.2021 12:34, Roger Pau Monné wrote:
>>> On Wed, Feb 10, 2021 at 12:10:09PM +0100, Jan Beulich wrote:
On 10.02.2021 09:29, Roger Pau Monné wrote:
> I get the feeling this is just papering over an e
On 10/02/2021 11:45, Jan Beulich wrote:
On 10.02.2021 12:40, Julien Grall wrote:
On 10/02/2021 11:38, Jan Beulich wrote:
On 10.02.2021 12:34, Roger Pau Monné wrote:
On Wed, Feb 10, 2021 at 12:10:09PM +0100, Jan Beulich wrote:
On 10.02.2021 09:29, Roger Pau Monné wrote:
I get the feeling t
On Wed, Feb 10, 2021 at 11:48:40AM +, Julien Grall wrote:
>
>
> On 10/02/2021 11:45, Jan Beulich wrote:
> > On 10.02.2021 12:40, Julien Grall wrote:
> > > On 10/02/2021 11:38, Jan Beulich wrote:
> > > > On 10.02.2021 12:34, Roger Pau Monné wrote:
> > > > > On Wed, Feb 10, 2021 at 12:10:09PM +
On 10/02/2021 10:55, Jan Beulich wrote:
> On 09.02.2021 22:49, Andrew Cooper wrote:
>> Currently, a failure of verify_patch_size() causes an early abort of the
>> microcode blob loop, which in turn causes a second go around the main
>> container loop, ultimately failing the UCODE_MAGIC check.
>>
>>
On 10/02/2021 09:57, Jan Beulich wrote:
> When invoked by compat mode, mode_64bit() will be false at the start of
> emulation. The logic after complete_insn, however, needs to consider the
> mode switched into, in particular to avoid truncating RIP.
>
> Inspired by / paralleling and extending Linux
On 10/02/2021 11:00, Jan Beulich wrote:
> On 10.02.2021 00:40, Andrew Cooper wrote:
>> verify_patch_size() is a maximum size check, and doesn't have a minimum
>> bound.
>>
>> If the microcode container encodes a blob with a length less than 64 bytes,
>> the subsequent calls to microcode_fits()/com
On 10/02/2021 08:37, Jan Beulich wrote:
> On 09.02.2021 18:39, Andrew Cooper wrote:
>> On 09/02/2021 17:17, Ian Jackson wrote:
>>> Jan Beulich writes ("Re: [PATCH for-4.15] x86/ucode: Fix microcode payload
>>> size for Fam19 processors"):
On 09.02.2021 16:33, Andrew Cooper wrote:
> The or
On 10.02.2021 12:48, Julien Grall wrote:
>
>
> On 10/02/2021 11:45, Jan Beulich wrote:
>> On 10.02.2021 12:40, Julien Grall wrote:
>>> On 10/02/2021 11:38, Jan Beulich wrote:
On 10.02.2021 12:34, Roger Pau Monné wrote:
> On Wed, Feb 10, 2021 at 12:10:09PM +0100, Jan Beulich wrote:
>>
On Tue, Feb 09, 2021 at 11:29:13AM +0100, Thomas Zimmermann wrote:
> The function drm_gem_fb_prepare_fb() is a helper for atomic modesetting,
> but currently located next to framebuffer helpers. Move it to GEM atomic
> helpers, rename it slightly and adopt the drivers. Same for the rsp
> simple-pip
On 10.02.2021 12:54, Roger Pau Monné wrote:
> On Wed, Feb 10, 2021 at 11:48:40AM +, Julien Grall wrote:
>> It feels wrong to me to setup a per-domain mapping when initializing the
>> first vCPU.
>>
>> But, I was under the impression that there is plan to remove
>> XEN_DOMCTL_max_vcpus. So it wo
flight 159206 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159206/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 159191
build-arm64-
Matches the comment in the xl-network-configuration manpage.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Anthony PERARD
---
tools/libs/light/libxl_nic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/libs/light/libxl_nic.c b/tools/libs/light/libxl_nic.c
index 1
On 10.02.2021 13:28, Andrew Cooper wrote:
> On 10/02/2021 09:57, Jan Beulich wrote:
>> When invoked by compat mode, mode_64bit() will be false at the start of
>> emulation. The logic after complete_insn, however, needs to consider the
>> mode switched into, in particular to avoid truncating RIP.
>>
On 10/02/2021 13:54, Jan Beulich wrote:
> On 10.02.2021 13:28, Andrew Cooper wrote:
>> On 10/02/2021 09:57, Jan Beulich wrote:
>>> When invoked by compat mode, mode_64bit() will be false at the start of
>>> emulation. The logic after complete_insn, however, needs to consider the
>>> mode switched i
Hi
Am 10.02.21 um 14:10 schrieb Daniel Vetter:
On Tue, Feb 09, 2021 at 11:29:13AM +0100, Thomas Zimmermann wrote:
The function drm_gem_fb_prepare_fb() is a helper for atomic modesetting,
but currently located next to framebuffer helpers. Move it to GEM atomic
helpers, rename it slightly and ado
On 09.02.2021 22:14, Julien Grall wrote:
> On Tue, 9 Feb 2021 at 20:28, Paul Durrant wrote:
>>> From: Julien Grall
>>> Sent: 09 February 2021 15:28
>>>
>>> It is a bit pointless to crash a domain that is already dying. This will
>>> become more an annoyance with a follow-up change where page-tabl
On 10.02.2021 15:02, Andrew Cooper wrote:
> On 10/02/2021 13:54, Jan Beulich wrote:
>> On 10.02.2021 13:28, Andrew Cooper wrote:
>>> On 10/02/2021 09:57, Jan Beulich wrote:
When invoked by compat mode, mode_64bit() will be false at the start of
emulation. The logic after complete_insn, ho
Invoking x86_init.irqs.create_pci_msi_domain() before
x86_init.pci.arch_init() breaks XEN PV.
The XEN_PV specific pci.arch_init() function overrides the default
create_pci_msi_domain() which is obviously too late.
As a consequence the XEN PV PCI/MSI allocation goes through the native
path which r
On 09.02.2021 16:28, Julien Grall wrote:
> From: Julien Grall
>
> The new IOMMU page-tables allocator will release the pages when
> relinquish the domain resources. However, this is not sufficient when
> the domain is dying because nothing prevents page-table to be allocated.
>
> iommu_alloc_pgt
On 09.02.2021 16:28, Julien Grall wrote:
> From: Julien Grall
>
> The new per-domain IOMMU page-table allocator will now free the
> page-tables when domain's resources are relinquished. However, the root
> page-table (i.e. hd->arch.pg_maddr) will not be cleared.
>
> Xen may access the IOMMU page
On 09.02.2021 16:28, Julien Grall wrote:
> @@ -303,9 +317,29 @@ struct page_info *iommu_alloc_pgtable(struct domain *d)
> unmap_domain_page(p);
>
> spin_lock(&hd->arch.pgtables.lock);
> -page_list_add(pg, &hd->arch.pgtables.list);
> +/*
> + * The IOMMU page-tables are freed
Hi Stefano,
> On 9 Feb 2021, at 19:53, Stefano Stabellini wrote:
>
> PCI buses differ from default buses in a few important ways, so it is
> important to detect them properly. Normally, PCI buses are expected to
> have the following property:
>
>device_type = "pci"
>
> In reality, it is no
Hi Jan,
On 10/02/2021 14:14, Jan Beulich wrote:
On 09.02.2021 22:14, Julien Grall wrote:
On Tue, 9 Feb 2021 at 20:28, Paul Durrant wrote:
From: Julien Grall
Sent: 09 February 2021 15:28
It is a bit pointless to crash a domain that is already dying. This will
become more an annoyance with a
On 10/02/2021 14:32, Jan Beulich wrote:
On 09.02.2021 16:28, Julien Grall wrote:
From: Julien Grall
The new IOMMU page-tables allocator will release the pages when
relinquish the domain resources. However, this is not sufficient when
the domain is dying because nothing prevents page-table t
Hello Stefano,
> On 9 Feb 2021, at 8:36 pm, Stefano Stabellini wrote:
>
> On Tue, 9 Feb 2021, Rahul Singh wrote:
>>> On 8 Feb 2021, at 6:49 pm, Stefano Stabellini
>>> wrote:
>>>
>>> Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
>>> The offending chunk is:
>>>
>>> #define gnttab_
On Wed, Feb 10, 2021 at 02:12:38PM +0100, Jan Beulich wrote:
> On 10.02.2021 12:54, Roger Pau Monné wrote:
> > On Wed, Feb 10, 2021 at 11:48:40AM +, Julien Grall wrote:
> >> It feels wrong to me to setup a per-domain mapping when initializing the
> >> first vCPU.
> >>
> >> But, I was under the
Invoking x86_init.irqs.create_pci_msi_domain() before
x86_init.pci.arch_init() breaks XEN PV.
The XEN_PV specific pci.arch_init() function overrides the default
create_pci_msi_domain() which is obviously too late.
As a consequence the XEN PV PCI/MSI allocation goes through the native
path which
flight 159210 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159210/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 159191
build-arm64-
On 10.02.2021 16:24, Roger Pau Monné wrote:
> On Wed, Feb 10, 2021 at 02:12:38PM +0100, Jan Beulich wrote:
>> On 10.02.2021 12:54, Roger Pau Monné wrote:
>>> On Wed, Feb 10, 2021 at 11:48:40AM +, Julien Grall wrote:
It feels wrong to me to setup a per-domain mapping when initializing the
>
On 10.02.2021 15:58, Julien Grall wrote:
> Hi Jan,
>
> On 10/02/2021 14:14, Jan Beulich wrote:
>> On 09.02.2021 22:14, Julien Grall wrote:
>>> On Tue, 9 Feb 2021 at 20:28, Paul Durrant wrote:
> From: Julien Grall
> Sent: 09 February 2021 15:28
>
> It is a bit pointless to crash a
Hello. Unfortunately we are having difficulty with osstest due to a
combination of an ill-timed Debian update and Linux kernel regressions
which got into the upstream stable trees and thence into Debian. I
have been working to try to resolve this situation. That has taken
time I should have been
On 10.02.2021 16:04, Julien Grall wrote:
> On 10/02/2021 14:32, Jan Beulich wrote:
>> On 09.02.2021 16:28, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> The new IOMMU page-tables allocator will release the pages when
>>> relinquish the domain resources. However, this is not sufficient when
>>
The address of this page is used by the CPU only to recognize when to
instead access the virtual APIC page instead. No accesses would ever go
to this page. It only needs to be present in the (CPU) page tables so
that address translation will produce its address as result for
respective accesses.
B
On 09.02.2021 17:26, Roger Pau Monné wrote:
> On Thu, Jan 14, 2021 at 04:04:57PM +0100, Jan Beulich wrote:
>> --- a/xen/arch/x86/usercopy.c
>> +++ b/xen/arch/x86/usercopy.c
>> @@ -10,12 +10,19 @@
>> #include
>> #include
>>
>> -unsigned __copy_to_user_ll(void __user *to, const void *from, unsi
On 10/02/2021 16:48, Jan Beulich wrote:
> The address of this page is used by the CPU only to recognize when to
> instead access the virtual APIC page instead. No accesses would ever go
> to this page. It only needs to be present in the (CPU) page tables so
> that address translation will produce i
On 10.02.2021 18:00, Andrew Cooper wrote:
> On 10/02/2021 16:48, Jan Beulich wrote:
>> The address of this page is used by the CPU only to recognize when to
>> instead access the virtual APIC page instead. No accesses would ever go
>> to this page. It only needs to be present in the (CPU) page tabl
From: Julien Grall
After Commit 3499ba8198cad ("xen: Fix event channel callback via
INTX/GSI"), xenbus_probe() will be called too early on Arm. This will
recent to a guest hang during boot.
If there hang wasn't there, we would have ended up to call
xenbus_probe() twice (the second time is in xen
On 10.02.2021 18:00, Andrew Cooper wrote:
> On 10/02/2021 16:48, Jan Beulich wrote:
>> The address of this page is used by the CPU only to recognize when to
>> instead access the virtual APIC page instead. No accesses would ever go
>> to this page. It only needs to be present in the (CPU) page tabl
Hi,
On 10/02/2021 15:06, Rahul Singh wrote:
On 9 Feb 2021, at 8:36 pm, Stefano Stabellini wrote:
On Tue, 9 Feb 2021, Rahul Singh wrote:
On 8 Feb 2021, at 6:49 pm, Stefano Stabellini wrote:
Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
The offending chunk is:
#define gnttab_nee
It seems that
CC: Julien Grall
CC: Stefano Stabellini
Signed-off-by: Ian Jackson
---
production-config | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/production-config b/production-config
index f783af3c..d89257e5 100644
--- a/production-config
+++ b/production-config
security updates are a separate apt source.
The point of using snapshot is to avoid pulling in uncontrolled
updates, so we need to disable security updates.
The non-security SUITE-updates are disabled by this too. But
everything is on fire and I don't want another iteration while I
figure out th
Signed-off-by: Ian Jackson
---
production-config | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/production-config b/production-config
index d89257e5..81582ec0 100644
--- a/production-config
+++ b/production-config
@@ -91,7 +91,7 @@ TftpNetbootGroup osstest
TftpDiVersion_whee
On Wed, 2021-02-10 at 17:06 +, Julien Grall wrote:
> From: Julien Grall
>
> After Commit 3499ba8198cad ("xen: Fix event channel callback via
> INTX/GSI"), xenbus_probe() will be called too early on Arm. This will
> recent to a guest hang during boot.
>
> If there hang wasn't there, we would
Hello Julien,
> On 10 Feb 2021, at 5:34 pm, Julien Grall wrote:
>
> Hi,
>
> On 10/02/2021 15:06, Rahul Singh wrote:
>>> On 9 Feb 2021, at 8:36 pm, Stefano Stabellini
>>> wrote:
>>>
>>> On Tue, 9 Feb 2021, Rahul Singh wrote:
> On 8 Feb 2021, at 6:49 pm, Stefano Stabellini
> wrote:
>
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
On 10/02/2021 18:08, Rahul Singh wrote:
Hello Julien,
On 10 Feb 2021, at 5:34 pm, Julien Grall wrote:
Hi,
On 10/02/2021 15:06, Rahul Singh wrote:
On 9 Feb 2021, at 8:36 pm, Stefano Stabellini wrote:
On Tue, 9 Feb 2021, Rahul Singh wrote:
On 8 Feb 2021, at 6:49 pm, Stefano Stabellini
On 10/02/2021 14:18, Jan Beulich wrote:
> On 10.02.2021 15:02, Andrew Cooper wrote:
>> On 10/02/2021 13:54, Jan Beulich wrote:
>>> Just like considered in the post-description
>>> remark, we could drop the conditional part from sysexit's
>>> setting of _regs.r(ip), and _then_ we would indeed need a
On Wed, 10 Feb 2021, Rahul Singh wrote:
> > On 9 Feb 2021, at 8:36 pm, Stefano Stabellini
> > wrote:
> > On Tue, 9 Feb 2021, Rahul Singh wrote:
> >>> On 8 Feb 2021, at 6:49 pm, Stefano Stabellini
> >>> wrote:
> >>>
> >>> Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
> >>> The offe
On Wed, 10 Feb 2021, Woodhouse, David wrote:
> On Wed, 2021-02-10 at 17:06 +, Julien Grall wrote:
> > From: Julien Grall
> >
> > After Commit 3499ba8198cad ("xen: Fix event channel callback via
> > INTX/GSI"), xenbus_probe() will be called too early on Arm. This will
> > recent to a guest han
flight 159220 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159220/
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
As started by commit 05a5f51ca566 ("Documentation: Replace lkml.org
links with lore"), replace lkml.org links with lore to better use a
single source that's more likely to stay available long-term.
Signed-off-by: Kees Cook
---
drivers/xen/xen-acpi-processor.c | 3 ++-
1 file changed, 2 insertion
Hello,
Last things first, some examples:
http://xenbits.xen.org/people/andrewcoop/abi/libxenevtchn-1.1_to_1.2.html
http://xenbits.xen.org/people/andrewcoop/abi/libxenforeignmemory-1.3_to_1.4.html
These are an ABI compatibility report between RELEASE-4.14.0 and staging.
They're performed with ab
On Tue, 2 Feb 2021, Daniel P. Smith wrote:
> This is a Request For Comments on the adoption of Device Tree as the
> format for the Launch Control Module as described in the previously
> posted DomB RFC.
>
> For RFC purposes, a rendered of this file can be found here:
> ihttps://drive.google.com/fi
flight 159200 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159200/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 14 guest-start fail REGR. vs. 158387
test-arm64-arm64-xl
flight 159201 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159201/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt broken
test-amd64-amd64-amd64-pvgrub
On 10.02.21 18:06, Julien Grall wrote:
From: Julien Grall
After Commit 3499ba8198cad ("xen: Fix event channel callback via
INTX/GSI"), xenbus_probe() will be called too early on Arm. This will
recent to a guest hang during boot.
If there hang wasn't there, we would have ended up to call
xenbus
The if condition in irq_matrix_reserve() can be much simpler.
While at it fix a typo in the comment.
Signed-off-by: Juergen Gross
---
kernel/irq/matrix.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/kernel/irq/matrix.c b/kernel/irq/matrix.c
index 651a4ad6d711..1f02a5
82 matches
Mail list logo
