So one thing that has been on my mind for a while: I'd really like
to kill the separate dma ops in Xen swiotlb. If we compare xen-swiotlb
to swiotlb the main difference seems to be:
- additional reasons to bounce I/O vs the plain DMA capable
- the possibility to do a hypercall on arm/arm64
-
> -Original Message-
> From: Jan Beulich
> Sent: 02 February 2021 15:14
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; George Dunlap
> Subject: [PATCH v2 1/2] IOREQ: fix waiting for broadcast completion
>
> Checking just a single server is not enough - all of them must have
>
Hi Jan,
Thank you for your reply.
On Wed, Feb 03, 2021 at 03:55:07PM +0100, Jan Beulich wrote:
> On 01.02.2021 16:26, James Dingwall wrote:
> > I am building the xen 4.11 branch at
> > 310ab79875cb705cc2c7daddff412b5a4899f8c9 which includes commit
> > 3b5de119f0399cbe745502cb6ebd5e6633cc139c "8
On 04.02.2021 09:46, James Dingwall wrote:
> On Wed, Feb 03, 2021 at 03:55:07PM +0100, Jan Beulich wrote:
>> On 01.02.2021 16:26, James Dingwall wrote:
>>> I am building the xen 4.11 branch at
>>> 310ab79875cb705cc2c7daddff412b5a4899f8c9 which includes commit
>>> 3b5de119f0399cbe745502cb6ebd5e663
> -Original Message-
> From: Jan Beulich
> Sent: 02 February 2021 15:15
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Wei Liu ; Roger
> Pau Monné
> ; Paul Durrant ; Julien Grall
> ; Stefano Stabellini
> ; George Dunlap
> Subject: [PATCH v2 2/2] IOREQ: refine when to send
X86_VENDOR_* aren't bit masks in the older trees.
Reported-by: James Dingwall
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -226,7 +226,8 @@ int guest_rdmsr(const struct vcpu *v, ui
*/
case MSR_IA32_PERF_STATUS:
case MSR_IA32_PERF_CTL:
-
Introduce an autoconf macro to check for the include path of certain
headers that can be different between OSes.
Use such macro to find the correct path for the endian.h header, and
modify the users of endian.h to use the output of such check.
Suggested-by: Ian Jackson
Signed-off-by: Roger Pau M
On Thu, Feb 04, 2021 at 10:36:06AM +0100, Jan Beulich wrote:
> X86_VENDOR_* aren't bit masks in the older trees.
>
> Reported-by: James Dingwall
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Should this have a set of Fixes tag for the commit hashes on <= 4.12?
Thanks, Roger.
On 04.02.2021 10:38, Roger Pau Monne wrote:
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -74,6 +74,7 @@ m4_include([../m4/ax_compare_version.m4])
> m4_include([../m4/paths.m4])
> m4_include([../m4/systemd.m4])
> m4_include([../m4/golang.m4])
> +m4_include([../m4/header.m4])
>
>
On 04.02.2021 10:40, Roger Pau Monné wrote:
> On Thu, Feb 04, 2021 at 10:36:06AM +0100, Jan Beulich wrote:
>> X86_VENDOR_* aren't bit masks in the older trees.
>>
>> Reported-by: James Dingwall
>> Signed-off-by: Jan Beulich
>
> Acked-by: Roger Pau Monné
Thanks.
> Should this have a set of Fix
On Thu, Feb 04, 2021 at 10:46:58AM +0100, Jan Beulich wrote:
> On 04.02.2021 10:38, Roger Pau Monne wrote:
> > --- a/tools/configure.ac
> > +++ b/tools/configure.ac
> > @@ -74,6 +74,7 @@ m4_include([../m4/ax_compare_version.m4])
> > m4_include([../m4/paths.m4])
> > m4_include([../m4/systemd.m4])
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-libvirt
testid guest-start
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tr
On 04.02.2021 10:59, Roger Pau Monné wrote:
> On Thu, Feb 04, 2021 at 10:46:58AM +0100, Jan Beulich wrote:
>> On 04.02.2021 10:38, Roger Pau Monne wrote:
>>> --- a/tools/configure.ac
>>> +++ b/tools/configure.ac
>>> @@ -74,6 +74,7 @@ m4_include([../m4/ax_compare_version.m4])
>>> m4_include([../m4/
On Thu, Feb 04, 2021 at 11:13:43AM +0100, Jan Beulich wrote:
> On 04.02.2021 10:59, Roger Pau Monné wrote:
> > On Thu, Feb 04, 2021 at 10:46:58AM +0100, Jan Beulich wrote:
> >> On 04.02.2021 10:38, Roger Pau Monne wrote:
> >>> --- a/tools/configure.ac
> >>> +++ b/tools/configure.ac
> >>> @@ -74,6 +
On 03.02.2021 18:58, Roger Pau Monne wrote:
> --- a/xen/include/asm-x86/x86_64/efibind.h
> +++ b/xen/include/asm-x86/x86_64/efibind.h
> @@ -172,7 +172,7 @@ typedef uint64_t UINTN;
> #ifndef EFIAPI // Forces EFI calling conventions
> reguardless of compiler options
> #ifdef
On 04.02.2021 11:21, Roger Pau Monné wrote:
> On Thu, Feb 04, 2021 at 11:13:43AM +0100, Jan Beulich wrote:
>> On 04.02.2021 10:59, Roger Pau Monné wrote:
>>> On Thu, Feb 04, 2021 at 10:46:58AM +0100, Jan Beulich wrote:
On 04.02.2021 10:38, Roger Pau Monne wrote:
> --- a/tools/configure.ac
Acked-by: Christian Lindig
From: Andrew Cooper
Sent: 03 February 2021 17:35
To: Xen-devel
Cc: Andrew Cooper; Christian Lindig; Ian Jackson; Wei Liu
Subject: [PATCH for-4.15 0/3] tools/oxenstored bugfixes
All of these been posted before, but were tangled
On Thu, Feb 04, 2021 at 11:32:41AM +0100, Jan Beulich wrote:
> On 04.02.2021 11:21, Roger Pau Monné wrote:
> > On Thu, Feb 04, 2021 at 11:13:43AM +0100, Jan Beulich wrote:
> >> On 04.02.2021 10:59, Roger Pau Monné wrote:
> >>> On Thu, Feb 04, 2021 at 10:46:58AM +0100, Jan Beulich wrote:
> On 0
Acked-by: Christian Lindig
Great work. Fuzzing is often thought as best to find bugs in languages like C
where memory is explicitly managed but here it reveals logical bugs.
From: Andrew Cooper
Sent: 03 February 2021 17:35
To: Xen-devel
Cc: Edwin Torok;
On Thu, Feb 04, 2021 at 11:27:17AM +0100, Jan Beulich wrote:
> On 03.02.2021 18:58, Roger Pau Monne wrote:
> > --- a/xen/include/asm-x86/x86_64/efibind.h
> > +++ b/xen/include/asm-x86/x86_64/efibind.h
> > @@ -172,7 +172,7 @@ typedef uint64_t UINTN;
> > #ifndef EFIAPI // Forces E
Acked-by: Christian Lindig
From: Andrew Cooper
Sent: 03 February 2021 17:35
To: Xen-devel
Cc: Edwin Torok; Christian Lindig; Ian Jackson; Wei Liu
Subject: [PATCH 3/3] tools/oxenstored: mkdir conflicts were sometimes missed
From: Edwin Török
Due to how
On 04.02.2021 11:51, Roger Pau Monné wrote:
> On Thu, Feb 04, 2021 at 11:27:17AM +0100, Jan Beulich wrote:
>> On 03.02.2021 18:58, Roger Pau Monne wrote:
>>> --- a/xen/include/asm-x86/x86_64/efibind.h
>>> +++ b/xen/include/asm-x86/x86_64/efibind.h
>>> @@ -172,7 +172,7 @@ typedef uint64_t UINTN;
>
On 02.02.21 11:17, Jiapeng Chong wrote:
Fix the following coccicheck warnings:
./drivers/net/xen-netfront.c:1816:52-54: WARNING !A || A && B is
equivalent to !A || B.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
On 28.01.21 16:50, Marek Marczykowski-Górecki wrote:
Using RING_GET_RESPONSE() on a shared ring is easy to use incorrectly
(i.e., by not considering that the other end may alter the data in the
shared ring while it is being inspected). Safe usage of a response
generally requires taking a local co
On 03.02.2021 17:04, Andrew Cooper wrote:
> On 02/02/2021 09:04, Jan Beulich wrote:
>> On 02.02.2021 00:26, Andrew Cooper wrote:
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -132,6 +132,56 @@ static void vcpu_info_reset(struct vcpu *v)
>>> v->vcpu_info_mfn = INVALID_MFN;
On 03.02.21 17:54, Manuel Bouyer wrote:
On error, don't keep socket connection in ignored state but close them.
When the remote end of a socket is closed, xenstored will flag it as an
error and switch the connection to ignored. But on some OSes (e.g.
NetBSD), poll(2) will return only POLLIN in th
On Thu, Feb 04, 2021 at 12:11:02PM +0100, Jürgen Groß wrote:
> On 03.02.21 17:54, Manuel Bouyer wrote:
> > On error, don't keep socket connection in ignored state but close them.
> > When the remote end of a socket is closed, xenstored will flag it as an
> > error and switch the connection to ignor
On 04.02.21 12:16, Manuel Bouyer wrote:
On Thu, Feb 04, 2021 at 12:11:02PM +0100, Jürgen Groß wrote:
On 03.02.21 17:54, Manuel Bouyer wrote:
On error, don't keep socket connection in ignored state but close them.
When the remote end of a socket is closed, xenstored will flag it as an
error and
On 04.02.2021 10:26, Paul Durrant wrote:
>
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: 02 February 2021 15:15
>> To: xen-devel@lists.xenproject.org
>> Cc: Andrew Cooper ; Wei Liu ; Roger
>> Pau Monné
>> ; Paul Durrant ; Julien Grall
>> ; Stefano Stabellini
>> ; George Dunlap
Hi Jan,
On Thu, Feb 04, 2021 at 10:36:06AM +0100, Jan Beulich wrote:
> X86_VENDOR_* aren't bit masks in the older trees.
>
> Reported-by: James Dingwall
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -226,7 +226,8 @@ int guest_rdmsr(const struct vcpu
Roger Pau Monne writes ("[PATCH for-4.15] autoconf: check endian.h include
path"):
> Introduce an autoconf macro to check for the include path of certain
> headers that can be different between OSes.
>
> Use such macro to find the correct path for the endian.h header, and
> modify the users of en
Roger Pau Monné writes ("Re: [PATCH for-4.15] autoconf: check endian.h include
path"):
> On Thu, Feb 04, 2021 at 11:32:41AM +0100, Jan Beulich wrote:
> > On 04.02.2021 11:21, Roger Pau Monné wrote:
> > > I think having to replicate this logic in all places that include
> > > endian.h is cumbersome
Roger Pau Monne writes ("[PATCH for-4.15] x86/efi: enable MS ABI attribute on
clang"):
> Or else the EFI service calls will use the wrong calling convention.
>
> The __ms_abi__ attribute is available on all supported versions of
> clang.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Ian Jackso
Manuel Bouyer writes ("Re: [PATCH] xenstored: close socket connections on
error"):
> On Thu, Feb 04, 2021 at 12:11:02PM +0100, Jürgen Groß wrote:
> > On 03.02.21 17:54, Manuel Bouyer wrote:
> > > On error, don't keep socket connection in ignored state but close them.
> > > When the remote end of a
Andrew Cooper writes ("[PATCH for-4.15] tools/tests: Introduce a test for
acquire_resource"):
> For now, simply try to map 40 frames of grant table. This catches most of the
> basic errors with resource sizes found and fixed through the 4.15 dev window.
FTAOD
Release-Acked-by: Ian Jackson
On 2021-02-04 07:29, Christoph Hellwig wrote:
On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote:
This patch converts several swiotlb related variables to arrays, in
order to maintain stat/status for different swiotlb buffers. Here are
variables involved:
- io_tlb_start and io_tlb_end
Although there are a few things outstanding, we are now firmly into
the bugfixing phase of the Xen 4.15 release.
I searched my email (and my memory) and found four open blockers which
I have listed below, and one closed blocker.
I feel there are probably more issues out there, so please let me
kn
On 04/02/2021 12:12, Ian Jackson wrote:
> OPEN ISSUES
> ---
>
> A. HPET/PIT issue on newer Intel systems
>
> Information from
> Andrew Cooper
>
> | This has had literally tens of reports across the devel and users
> | mailing lists, and prevents Xen from booting at all on the past two
>
On 14.12.20 22:25, Julien Grall wrote:
Hi Juergen,
When testing Linux 5.10 dom0, I could reliably hit the following warning
with using event 2L ABI:
[ 589.591737] Interrupt for port 34, but apparently not enabled;
per-user a86a4c1b
[ 589.593259] WARNING: CPU: 0 PID: at
/home/
flight 159004 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159004/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On 04/02/2021 09:36, Jan Beulich wrote:
> X86_VENDOR_* aren't bit masks in the older trees.
>
> Reported-by: James Dingwall
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Hello,
the Xen project hypervisor build system includes building the
hypervisor binary as an EFI application, as an option (i.e.
as long as the tool chain supports this). Already when probing
the linker we now suddenly get several "relocation truncated
to fit:R_X86_64_32 against `.debug_...'" erro
Hi Andrew.
[Sorry for the possible format issues]
On Tue, Feb 2, 2021 at 9:10 PM Andrew Cooper
wrote:
> For now, simply try to map 40 frames of grant table. This catches most of
> the
> basic errors with resource sizes found and fixed through the 4.15 dev
> window.
>
> Signed-off-by: Andrew Coo
On Feb 04 2021, Jan Beulich via Binutils wrote:
> For reference, the probing is as simple as
>
> $(LD) -mi386pep --subsystem=10 -o efi/check.efi efi/check.o
>
> As was to be expected, the errors disappear with -S, but that's
> an option only for the probing, not for the actual linking of
> the bin
Our linker capability check fails with the recent binutils release's ld:
.../check.o:(.debug_aranges+0x6): relocation truncated to fit: R_X86_64_32
against `.debug_info'
.../check.o:(.debug_info+0x6): relocation truncated to fit: R_X86_64_32 against
`.debug_abbrev'
.../check.o:(.debug_info+0xc):
flight 158996 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158996/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 broken
test-arm64-arm64-xl-
On 04.02.2021 14:34, Andreas Schwab wrote:
> On Feb 04 2021, Jan Beulich via Binutils wrote:
>
>> For reference, the probing is as simple as
>>
>> $(LD) -mi386pep --subsystem=10 -o efi/check.efi efi/check.o
>>
>> As was to be expected, the errors disappear with -S, but that's
>> an option only for
On 29/01/2021 11:45, Jan Beulich wrote:
> There are three noteworthy drawbacks:
> 1) The intercepts we need to enable here are CPL-independent, i.e. we
>now have to emulate certain instructions for ring 0.
> 2) On VMX there's no intercept for SMSW, so the emulation isn't really
>complete th
On Thu, 2021-02-04 at 12:12 +, Ian Jackson wrote:
> B. "scheduler broken" bugs.
>
> Information from
> Andrew Cooper
> Dario Faggioli
>
> Quoting Andrew Cooper
> > We've had 4 or 5 reports of Xen not working, and very little
> > investigation on whats going on. Suspicion is that there
On 04.02.2021 13:12, Ian Jackson wrote:
> OPEN ISSUES
> ---
>
> A. HPET/PIT issue on newer Intel systems
> [...]
>
> B. "scheduler broken" bugs.
>
> Information from
> Andrew Cooper
> Dario Faggioli
>
> Quoting Andrew Cooper
> | We've had 4 or 5 reports of Xen not working, and ver
On Thu, Feb 4, 2021 at 9:21 AM Dario Faggioli wrote:
>
> On Thu, 2021-02-04 at 12:12 +, Ian Jackson wrote:
> > B. "scheduler broken" bugs.
> >
> > Information from
> > Andrew Cooper
> > Dario Faggioli
> >
> > Quoting Andrew Cooper
> > > We've had 4 or 5 reports of Xen not working, and ve
Dario Faggioli writes ("Re: [ANNOUNCE] Xen 4.15 - call for notification/status
of significant bugs"):
> On Thu, 2021-02-04 at 12:12 +, Ian Jackson wrote:
> > I reviewed a thread about this and it is not clear to me where we are
> > with this.
.
> Ok, let me try to summarize the current status.
Andrew Cooper writes ("Re: [ANNOUNCE] Xen 4.15 - call for notification/status
of significant bugs"):
> On 04/02/2021 12:12, Ian Jackson wrote:
> > OPEN ISSUES
> > ---
> >
> > A. HPET/PIT issue on newer Intel systems
...
> > I think Andrew is still on the case here.
>
> Fixed. c/s e1de4c1
Jan Beulich writes ("Re: [ANNOUNCE] Xen 4.15 - call for notification/status of
significant bugs"):
> On 04.02.2021 13:12, Ian Jackson wrote:
> > OPEN ISSUES
> > ---
...
> > I reviewed a thread about this and it is not clear to me where we are
> > with this.
>
> I'm not sure Marek's "Xen c
flight 159000 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159000/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f6ec1dd34fb6b9757b5ead465ee2ea20c182b0ac
baseline version:
ovmf e806bb29cfde1b242bb37
On 04.02.21 15:29, Oleksandr Tyshchenko wrote:
Hi Andrew
Hi Andrew.
[Sorry for the possible format issues]
On Tue, Feb 2, 2021 at 9:10 PM Andrew Cooper
mailto:andrew.coop...@citrix.com>> wrote:
For now, simply try to map 40 frames of grant table. This catches
most of the
basi
On 04/02/2021 15:38, Oleksandr wrote:
>>
>> Hi Andrew.
>> [Sorry for the possible format issues]
>>
>> On Tue, Feb 2, 2021 at 9:10 PM Andrew Cooper
>> mailto:andrew.coop...@citrix.com>> wrote:
>>
>> For now, simply try to map 40 frames of grant table. This
>> catches most of the
>> bas
On 04.02.2021 10:36, Jan Beulich wrote:
> X86_VENDOR_* aren't bit masks in the older trees.
>
> Reported-by: James Dingwall
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -226,7 +226,8 @@ int guest_rdmsr(const struct vcpu *v, ui
> */
> c
It is not permitted to edit the VERS clause for a version in a release of Xen.
Revert xendevicemodel_set_irq_level()'s inclusion in .so.1.2 and bump the the
library minor version to .so.1.4 instead.
Fixes: 5d752df85f ("xen/dm: Introduce xendevicemodel_set_irq_level DM op")
Signed-off-by: Andrew C
flight 159014 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159014/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
On 04/02/2021 15:53, Jan Beulich wrote:
> On 04.02.2021 10:36, Jan Beulich wrote:
>> X86_VENDOR_* aren't bit masks in the older trees.
>>
>> Reported-by: James Dingwall
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/msr.c
>> +++ b/xen/arch/x86/msr.c
>> @@ -226,7 +226,8 @@ int guest_rdmsr(
On 04/02/2021 00:13, Stefano Stabellini wrote:
On Wed, 3 Feb 2021, Julien Grall wrote:
On Wed, 3 Feb 2021 at 22:18, Stefano Stabellini wrote:
But aside from PCIe, let's say that we know of a few nodes for which
"reg" needs a special treatment. I am not sure it makes sense to proceed
with pa
Hi Andrew
On 04.02.21 17:44, Andrew Cooper wrote:
On 04/02/2021 15:38, Oleksandr wrote:
Hi Andrew.
[Sorry for the possible format issues]
On Tue, Feb 2, 2021 at 9:10 PM Andrew Cooper
mailto:andrew.coop...@citrix.com>> wrote:
For now, simply try to map 40 frames of grant table. This
On 04/02/2021 16:33, Oleksandr wrote:
> On 04.02.21 17:44, Andrew Cooper wrote:
>> On 04/02/2021 15:38, Oleksandr wrote:
>>>
>>>
>>> I got the following result without and with "[PATCH v9 01/11]
>>> xen/memory: Fix mapping grant tables with XENMEM_acquire_resource"
>>>
>>> root@generic-armv8-xt-dom
On 04.02.21 17:58, Andrew Cooper wrote:
Hi Andrew
It is not permitted to edit the VERS clause for a version in a release of Xen.
Revert xendevicemodel_set_irq_level()'s inclusion in .so.1.2 and bump the the
library minor version to .so.1.4 instead.
Fixes: 5d752df85f ("xen/dm: Introduce xend
Andrew Cooper writes ("[PATCH for-4.15] libs/devicemodel: Fix ABI breakage from
xendevicemodel_set_irq_level()"):
> It is not permitted to edit the VERS clause for a version in a release of Xen.
>
> Revert xendevicemodel_set_irq_level()'s inclusion in .so.1.2 and bump the the
> library minor vers
On 04/02/2021 16:50, Oleksandr wrote:
>
> On 04.02.21 17:58, Andrew Cooper wrote:
>
> Hi Andrew
>
>> It is not permitted to edit the VERS clause for a version in a
>> release of Xen.
>>
>> Revert xendevicemodel_set_irq_level()'s inclusion in .so.1.2 and bump
>> the the
>> library minor version to .
Hi Rob,
We have a question on the PCIe device tree bindings. In summary, we have
come across the Raspberry Pi 4 PCIe description below:
pcie0: pcie@7d50 {
compatible = "brcm,bcm2711-pcie";
reg = <0x0 0x7d50 0x0 0x9310>;
device_type = "pci";
#address-cells = <3>;
#interrup
On Thu, 2021-02-04 at 10:00 -0500, Tamas K Lengyel wrote:
> On Thu, Feb 4, 2021 at 9:21 AM Dario Faggioli
> wrote:
> >
> > On Thu, 2021-02-04 at 12:12 +, Ian Jackson wrote:
> > > B. "scheduler broken" bugs.
> >
> > - Null scheduler and vwfi native problem
> >
> > https://lists.xenproject
On Thu, Feb 4, 2021 at 11:56 AM Stefano Stabellini
wrote:
>
> Hi Rob,
>
> We have a question on the PCIe device tree bindings. In summary, we have
> come across the Raspberry Pi 4 PCIe description below:
>
>
> pcie0: pcie@7d50 {
>compatible = "brcm,bcm2711-pcie";
>reg = <0x0 0x7d50
On Thu, Feb 04, 2021 at 11:49:23AM +, Robin Murphy wrote:
> On 2021-02-04 07:29, Christoph Hellwig wrote:
> > On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote:
> > > This patch converts several swiotlb related variables to arrays, in
> > > order to maintain stat/status for different
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Tue, 2 Feb 2021 18:17:49 +0800 you wrote:
> Fix the following coccicheck warnings:
>
> ./drivers/net/xen-netfront.c:1816:52-54: WARNING !A || A && B is
> equivalent to !A || B.
>
> Reported-by: Abaci Robot
> Signed-o
flight 159020 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159020/
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 Thu, 4 Feb 2021, Rob Herring wrote:
> On Thu, Feb 4, 2021 at 11:56 AM Stefano Stabellini
> wrote:
> >
> > Hi Rob,
> >
> > We have a question on the PCIe device tree bindings. In summary, we have
> > come across the Raspberry Pi 4 PCIe description below:
> >
> >
> > pcie0: pcie@7d50 {
> >
flight 158997 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158997/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 broken
test-arm64-arm64-xl-seattle
On Thu, Feb 4, 2021 at 2:36 PM Stefano Stabellini
wrote:
>
> On Thu, 4 Feb 2021, Rob Herring wrote:
> > On Thu, Feb 4, 2021 at 11:56 AM Stefano Stabellini
> > wrote:
> > >
> > > Hi Rob,
> > >
> > > We have a question on the PCIe device tree bindings. In summary, we have
> > > come across the Rasp
On 01/02/2021 23:26, Andrew Cooper wrote:
> A guest's default number of grant frames is 64, and XENMEM_acquire_resource
> will reject an attempt to map more than 32 frames. This limit is caused by
> the size of mfn_list[] on the stack.
>
> Fix mapping of arbitrary size requests by looping over bat
On Thu, 4 Feb 2021, Rob Herring wrote:
> On Thu, Feb 4, 2021 at 2:36 PM Stefano Stabellini
> wrote:
> >
> > On Thu, 4 Feb 2021, Rob Herring wrote:
> > > On Thu, Feb 4, 2021 at 11:56 AM Stefano Stabellini
> > > wrote:
> > > >
> > > > Hi Rob,
> > > >
> > > > We have a question on the PCIe device tr
On Thu, Feb 4, 2021 at 3:33 PM Stefano Stabellini
wrote:
>
> On Thu, 4 Feb 2021, Rob Herring wrote:
> > On Thu, Feb 4, 2021 at 2:36 PM Stefano Stabellini
> > wrote:
> > >
> > > On Thu, 4 Feb 2021, Rob Herring wrote:
> > > > On Thu, Feb 4, 2021 at 11:56 AM Stefano Stabellini
> > > > wrote:
> > >
On Thu, 4 Feb 2021, Rob Herring wrote:
> On Thu, Feb 4, 2021 at 3:33 PM Stefano Stabellini
> wrote:
> >
> > On Thu, 4 Feb 2021, Rob Herring wrote:
> > > On Thu, Feb 4, 2021 at 2:36 PM Stefano Stabellini
> > > wrote:
> > > >
> > > > On Thu, 4 Feb 2021, Rob Herring wrote:
> > > > > On Thu, Feb 4, 2
On Thu, 4 Feb 2021, Julien Grall wrote:
> On 04/02/2021 00:13, Stefano Stabellini wrote:
> > On Wed, 3 Feb 2021, Julien Grall wrote:
> > > On Wed, 3 Feb 2021 at 22:18, Stefano Stabellini
> > > wrote:
> > > > > > But aside from PCIe, let's say that we know of a few nodes for which
> > > > > > "reg"
flight 159005 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159005/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 159025 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159025/
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 Thu, 4 Feb 2021, Jukka Kaartinen wrote:
> We really need direct HW access so PVFB is not really an option. And at this
> point. We can trust the VMs.
>
>
> Any idea what am I missing something here is this the way to give domu access
> to the memory?
>
> # from dom0: cat /proc/iomem
> # fe104
On Thu, 4 Feb 2021 06:32:32 +0100 Jürgen Groß wrote:
> On 04.02.21 00:48, Jakub Kicinski wrote:
> > On Tue, 2 Feb 2021 08:09:38 +0100 Juergen Gross wrote:
> >> Since commit 23025393dbeb3b8b3 ("xen/netback: use lateeoi irq binding")
> >> xenvif_rx_ring_slots_available() is no longer called only f
On Thu, Feb 04, 2021 at 03:52:26PM -0600, Rob Herring wrote:
> On Thu, Feb 4, 2021 at 3:33 PM Stefano Stabellini
> wrote:
> >
> > On Thu, 4 Feb 2021, Rob Herring wrote:
> > > On Thu, Feb 4, 2021 at 2:36 PM Stefano Stabellini
> > > wrote:
> > > >
> > > > On Thu, 4 Feb 2021, Rob Herring wrote:
> >
flight 159029 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159029/
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
test-armhf-arm
flight 159009 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159009/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 159033 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159033/
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
89 matches
Mail list logo
