On 2024-09-17 08:13, Bertrand Marquis wrote:
Hi Stefano,
On 17 Sep 2024, at 01:02, Stefano Stabellini
wrote:
The Xen community is already informally following both rules. Let's
make
it explicit. Both rules have zero violations, only cautions. While we
want to go down to zero cautions in ti
flight 187725 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187725/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187717
test-amd64-amd64-xl-qemut-win7-amd64
Hi Stefano,
> On 17 Sep 2024, at 01:02, Stefano Stabellini wrote:
>
> The Xen community is already informally following both rules. Let's make
> it explicit. Both rules have zero violations, only cautions. While we
> want to go down to zero cautions in time, adding both rules to rules.rst
> enab
From: "Dr. David Alan Gilbert"
xen_be_copy_grant_refs is unused since 2019's
19f87870ba ("xen: remove the legacy 'xen_disk' backend")
xen_config_dev_console is unused since 2018's
6d7c06c213 ("Remove broken Xen PV domain builder")
Remove them.
Signed-off-by: Dr. David Alan Gilbert
---
hw
flight 187726 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187726/
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
flight 187723 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187723/
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 Mon, 16 Sep 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Enable PCI support for the ARM Xen PVH machine.
>
> Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
> ---
> hw/arm/xen-pvh.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --gi
On Mon, 16 Sep 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Signed-off-by: Edgar E. Iglesias
Acked-by: Stefano Stabellini
> ---
> hw/xen/xen-pvh-common.c | 36
> 1 file changed, 36 insertions(+)
>
> diff --git a/hw/xen/xen-pvh-common.c
On Mon, 16 Sep 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Add a way to enable/disable buffered IOREQs for PVH machines
> and disable them for ARM. ARM does not support buffered
> IOREQ's nor the legacy way to map IOREQ info pages.
>
> See the following for more details:
> htt
On Mon, 16 Sep 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Expose handle_bufioreq in xen_register_ioreq().
> This is to allow machines to enable or disable buffered ioreqs.
>
> No functional change since all callers still set it to
> HVM_IOREQSRV_BUFIOREQ_ATOMIC.
>
> Signed-o
On Mon, 16 Sep 2024, Julien Grall wrote:
> On 13/09/2024 08:43, Julien Grall wrote:
> > On 12/09/2024 23:44, Stefano Stabellini wrote:
> > > On Thu, 12 Sep 2024, Bertrand Marquis wrote:
> > > > Hi Andrei,
> > > >
> > > > > On 11 Sep 2024, at 23:05, Andrei Cherechesu
> > > > > wrote:
> > > > >
>
The Xen community is already informally following both rules. Let's make
it explicit. Both rules have zero violations, only cautions. While we
want to go down to zero cautions in time, adding both rules to rules.rst
enables us to immediately make both rules gating in the ECLAIR job part
of gitlab-c
flight 187721 linux-linus real [real]
flight 187724 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187721/
http://logs.test-lab.xenproject.org/osstest/logs/187724/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
Hi Jan,
On 11/09/2024 13:19, Jan Beulich wrote:
Returning a literal number is a bad idea anyway when all other returns
use IOREQ_STATUS_* values. While that's maybe intended on Arm (mapping
to IO_ABORT),
Arm doesn't support buffered ioreq (see ioreq_server_create()) and
AFAICT the "0" was al
Hi,
On 13/09/2024 08:43, Julien Grall wrote:
On 12/09/2024 23:44, Stefano Stabellini wrote:
On Thu, 12 Sep 2024, Bertrand Marquis wrote:
Hi Andrei,
On 11 Sep 2024, at 23:05, Andrei Cherechesu
wrote:
Hi Julien, Stefano,
On 11/09/2024 08:19, Stefano Stabellini wrote:
On Tue, 10 Sep 2024, J
Hi,
On 11/09/2024 10:17, Julien Grall wrote:
On 10/09/2024 15:34, Andrei Cherechesu (OSS) wrote:
From: Andrei Cherechesu
All versions of Cortex-A53 cores are affected by the speculative
AT instruction erratum, as mentioned in the Cortex-A53 Revision r0
SDEN v21 documentation.
Enabled ARM64_W
Hi,
On 13/09/2024 09:26, Andrew Cooper wrote:
On 13/09/2024 7:15 am, Michal Orzel wrote:
The predefined configurations for early printk have been deprecated for
a sufficient amount of time. Let's finally remove them.
Note:
In order not to loose these predefined configurations, I wrote a wiki
p
From: Roger Pau Monne
When running as a PVH dom0 the ACPI MADT is crafted by Xen in order to
report the correct numbers of vCPUs that dom0 has, so the host MADT is
not provided to dom0. This creates issues when parsing the power and
performance related data from ACPI dynamic tables, as the ACPI
On Mon, 16 Sep 2024, Juergen Gross wrote:
> On 16.09.24 08:56, Juergen Gross wrote:
> > On 16.09.24 08:50, Jan Beulich wrote:
> > > On 16.09.2024 08:47, Juergen Gross wrote:
> > > > --- a/drivers/xen/swiotlb-xen.c
> > > > +++ b/drivers/xen/swiotlb-xen.c
> > > > @@ -78,9 +78,15 @@ static inline int
On Mon, 16 Sep 2024, Jan Beulich wrote:
> On 16.09.2024 08:47, Juergen Gross wrote:
> > The allocated size in xen_swiotlb_alloc_coherent() and
> > xen_swiotlb_free_coherent() is calculated wrong for the case of
> > XEN_PAGE_SIZE not matching PAGE_SIZE. Fix that.
> >
> > Fixes: 7250f422da04 ("xen-s
On Mon, 16 Sep 2024, Roger Pau Monné wrote:
> On Mon, Sep 16, 2024 at 09:37:57AM +0300, Sergiy Kibrik wrote:
> > Introduce config option X86_PMTIMER so that pmtimer driver can be disabled
> > on
> > systems that don't need it.
>
> Same comment as in the VGA patch, you need to handle the user pass
flight 187722 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187722/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 670e263419eb875fd8dce0c8d18dd3ab02b83ba0
baseline version:
ovmf 7843c8da060484cdb4239
flight 187720 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187720/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 187701
test-amd64-amd64-qemuu-nested-amd 2
On Fri, 2024-09-13 at 19:45 +0200, Jan Beulich wrote:
> On 13.09.2024 16:35, oleksii.kuroc...@gmail.com wrote:
> > On Thu, 2024-09-12 at 17:28 +0200, Jan Beulich wrote:
> > > On 11.09.2024 12:04, Oleksii Kurochko wrote:
> > > > --- a/xen/common/Makefile
> > > > +++ b/xen/common/Makefile
> > > > @@
From: "Edgar E. Iglesias"
Enable PCI support for the ARM Xen PVH machine.
Signed-off-by: Edgar E. Iglesias
---
hw/arm/xen-pvh.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/hw/arm/xen-pvh.c b/hw/arm/xen-pvh.c
index 28af3910ea..33f0dd5982 100644
--- a/hw/arm/xen-pvh.c
+++
From: "Edgar E. Iglesias"
Enable PCI on the ARM PVH machine. First we add a way to control the use
of buffered IOREQ's since those are not supported on Xen/ARM.
Finally we enable the PCI support.
I've published some instructions on how to try this including the work in
progress Xen side of the P
From: "Edgar E. Iglesias"
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-pvh-common.c | 36
1 file changed, 36 insertions(+)
diff --git a/hw/xen/xen-pvh-common.c b/hw/xen/xen-pvh-common.c
index 76a9b2b945..218ac851cf 100644
--- a/hw/xen/xen-pvh-common.c
++
From: "Edgar E. Iglesias"
Add a way to enable/disable buffered IOREQs for PVH machines
and disable them for ARM. ARM does not support buffered
IOREQ's nor the legacy way to map IOREQ info pages.
See the following for more details:
https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=2fbd7e60
From: "Edgar E. Iglesias"
Expose handle_bufioreq in xen_register_ioreq().
This is to allow machines to enable or disable buffered ioreqs.
No functional change since all callers still set it to
HVM_IOREQSRV_BUFIOREQ_ATOMIC.
Signed-off-by: Edgar E. Iglesias
---
hw/i386/xen/xen-hvm.c |
On Mon, Sep 16, 2024 at 03:20:56PM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Sep 16, 2024 at 02:11:08PM +0100, Andrew Cooper wrote:
> > On 13/09/2024 8:59 am, Roger Pau Monne wrote:
> > > diff --git a/docs/misc/xen-command-line.pandoc
> > > b/docs/misc/xen-command-line.pandoc
> > > index
On 16/09/2024 2:16 pm, Frediano Ziglio wrote:
> On Mon, Sep 16, 2024 at 12:58 PM Andrew Cooper
> wrote:
>> This used to be true, but was altered by commit 37786b23b027 ("x86/cet:
>> Remove
>> writeable mapping of the BSPs shadow stack") which moved cpu0_stack into
>> .init.bss.stack_aligned.
>>
>
On Mon, Sep 16, 2024 at 02:11:08PM +0100, Andrew Cooper wrote:
> On 13/09/2024 8:59 am, Roger Pau Monne wrote:
> > diff --git a/docs/misc/xen-command-line.pandoc
> > b/docs/misc/xen-command-line.pandoc
> > index 959cf45b55d9..2a9b3b9b8975 100644
> > --- a/docs/misc/xen-command-line.pandoc
> > +++
On Mon, Sep 16, 2024 at 12:58 PM Andrew Cooper
wrote:
>
> This used to be true, but was altered by commit 37786b23b027 ("x86/cet: Remove
> writeable mapping of the BSPs shadow stack") which moved cpu0_stack into
> .init.bss.stack_aligned.
>
> Fixes: 37786b23b027 ("x86/cet: Remove writeable mapping
On 13/09/2024 8:59 am, Roger Pau Monne wrote:
> The EFI_GET_TIME implementation is well known to be broken for many firmware
> implementations, for Xen the result on such implementations are:
>
> [ Xen-4.19-unstable x86_64 debug=y Tainted: C]
> CPU:0
> RIP:e008:[<62
On 13/09/2024 8:59 am, Roger Pau Monne wrote:
> diff --git a/docs/misc/xen-command-line.pandoc
> b/docs/misc/xen-command-line.pandoc
> index 959cf45b55d9..2a9b3b9b8975 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -2816,6 +2816,27 @@ vwfi to `nativ
On Mon, Sep 16, 2024 at 1:29 PM Frediano Ziglio
wrote:
>
...
> >
> > Independently, given the adjustment in this patch, we should just make
> > trampoline.o a proper object and take it out of head.S That's one fewer
> > non-standard moving parts in the build.
> >
>
> I think another hidden assump
flight 187717 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187717/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187714
test-amd64-amd64-xl-qemut-win7-amd64
On Mon, Sep 16, 2024 at 12:11 PM Andrew Cooper
wrote:
>
> On 16/09/2024 10:44 am, Frediano Ziglio wrote:
> > This change put the trampoline in a separate, not executable section.
> > The trampoline contains a mix of code and data (data which
> > is modified from C code during early start so must b
From: Michal Orzel
AoU are the assumptions that Xen relies on other components (eg platform
platform, domains)
to fulfill its requirements. In our case, platform means a combination
of hardware, firmware and bootloader.
We have defined AoU in the intro.rst and added AoU for the generic
timer.
A
On 16.09.2024 10:02, Frediano Ziglio wrote:
> On Sun, Sep 15, 2024 at 7:16 AM Jan Beulich wrote:
>>
>> On 10.09.2024 18:16, Frediano Ziglio wrote:
>>> --- a/xen/arch/x86/boot/head.S
>>> +++ b/xen/arch/x86/boot/head.S
>>> @@ -25,6 +25,9 @@
>>> #define MB2_HT(name) (MULTIBOOT2_HEADER_TAG_##nam
This used to be true, but was altered by commit 37786b23b027 ("x86/cet: Remove
writeable mapping of the BSPs shadow stack") which moved cpu0_stack into
.init.bss.stack_aligned.
Fixes: 37786b23b027 ("x86/cet: Remove writeable mapping of the BSPs shadow
stack")
Signed-off-by: Andrew Cooper
---
CC:
On 16.09.2024 11:11, Frediano Ziglio wrote:
> On Sat, Sep 14, 2024 at 7:16 AM Jan Beulich wrote:
>> On 11.09.2024 11:55, Frediano Ziglio wrote:
>>> + DECL_SECTION(.init.trampoline) {
>>> + *(.init.trampoline)
>>> + } PHDR(text)
>>> +
>>> #ifndef EFI
>>
>> If this is to be a separate secti
flight 187719 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187719/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7843c8da060484cdb4239078544cab807377070d
baseline version:
ovmf be36ddb23463e02384061
On 16.09.2024 11:35, Frediano Ziglio wrote:
> --- a/xen/arch/x86/include/asm/x86_64/efibind.h
> +++ b/xen/arch/x86/include/asm/x86_64/efibind.h
> @@ -176,7 +176,7 @@ typedef uint64_t UINTN;
> #elif __clang__ || __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4)
> #define EFIAPI
On 16/09/2024 10:44 am, Frediano Ziglio wrote:
> This change put the trampoline in a separate, not executable section.
> The trampoline contains a mix of code and data (data which
> is modified from C code during early start so must be writable).
> This is in preparation for W^X patch in order to s
On Mon, 2024-09-16 at 08:48 +0200, Jan Beulich wrote:
> On 13.09.2024 17:57, Oleksii Kurochko wrote:
> > Introduce struct pcpu_info to store pCPU-related information.
> > Initially, it includes only processor_id and hart id, but it
> > will be extended to include guest CPU information and
> > tempo
On Mon, 2024-09-16 at 08:32 +0200, Jan Beulich wrote:
> On 13.09.2024 17:57, Oleksii Kurochko wrote:
> > Set up fixmap mappings and the L0 page table for fixmap support.
> >
> > {set, clear}_fixmap() is expected to be implemented using
> > map_pages_to_xen(), which, in turn, is only expected to us
This change put the trampoline in a separate, not executable section.
The trampoline contains a mix of code and data (data which
is modified from C code during early start so must be writable).
This is in preparation for W^X patch in order to satisfy UEFI CA
memory mitigation requirements.
At the m
expresion -> expression
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/include/asm/x86_64/efibind.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/include/asm/x86_64/efibind.h
b/xen/arch/x86/include/asm/x86_64/efibind.h
index 28bc18c24b..b29342c61c 100644
---
On Sat, Sep 14, 2024 at 7:39 AM Jan Beulich wrote:
>
> On 28.08.2024 11:19, Frediano Ziglio wrote:
> > The trampoline could have "manual" relocation entries (created
> > by assembly macros and some code to use them) and (in case of PE)
> > normal executable relocations.
> > Remove some normal exec
flight 187718 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187718/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf be36ddb23463e0238406129eff1e89c56df561eb
baseline version:
ovmf 73dbb68006caf538d1b69
On Sat, Sep 14, 2024 at 7:16 AM Jan Beulich wrote:
>
> On 11.09.2024 11:55, Frediano Ziglio wrote:
> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@ -882,8 +882,9 @@ cmdline_parse_early:
> > reloc:
> > .incbin "reloc.bin"
> >
> > +#include "x86_64.S"
> > +
> >
On Mon, 2024-09-16 at 08:25 +0200, Jan Beulich wrote:
> On 13.09.2024 17:57, Oleksii Kurochko wrote:
> > Update the defintion of write_atomic() to support non-scalar types,
> > aligning it with the behavior of read_atomic().
>
> "Aligning" would imo imply yet more similarity. Types are different,
x86 maintainers,
are you going to pick this series up, or should I take it via the
Xen tree?
Juergen
On 23.08.24 21:36, Jason Andryuk wrote:
Using the PVH entry point, the uncompressed vmlinux is loaded at
LOAD_PHYSICAL_ADDR, and execution starts in 32bit mode at the
address in XEN_ELFNOTE_PH
On Sun, Sep 15, 2024 at 8:00 AM Jan Beulich wrote:
>
> On 10.09.2024 18:16, Frediano Ziglio wrote:
> > No need to have it coded in assembly.
>
> As to the title: It's the EFI/MB2 case you re-write. That wants reflecting
> there, as the "normal" EFI start part is all C already anyway. I also
> thin
On Mon, 16 Sep 2024 09:37:07 +0200,
Christoph Hellwig wrote:
>
> On Mon, Sep 16, 2024 at 09:30:11AM +0200, Takashi Iwai wrote:
> > On Mon, 16 Sep 2024 09:24:42 +0200,
> > Christoph Hellwig wrote:
> > >
> > > On Mon, Sep 16, 2024 at 09:16:58AM +0200, Takashi Iwai wrote:
> > > > Yes, all those are
On 16.09.24 09:59, Jan Beulich wrote:
On 16.09.2024 08:47, Juergen Gross wrote:
The allocated size in xen_swiotlb_alloc_coherent() and
xen_swiotlb_free_coherent() is calculated wrong for the case of
XEN_PAGE_SIZE not matching PAGE_SIZE. Fix that.
Fixes: 7250f422da04 ("xen-swiotlb: use actually
On 16.09.2024 09:44, Frediano Ziglio wrote:
> On Sun, Sep 15, 2024 at 7:20 AM Jan Beulich wrote:
>>
>> On 10.09.2024 18:16, Frediano Ziglio wrote:
>>> --- a/xen/arch/x86/boot/head.S
>>> +++ b/xen/arch/x86/boot/head.S
>>> @@ -231,6 +231,27 @@ __efi64_mb2_start:
>>> /* VGA is not available
On Sun, Sep 15, 2024 at 7:16 AM Jan Beulich wrote:
>
> On 10.09.2024 18:16, Frediano Ziglio wrote:
> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@ -25,6 +25,9 @@
> > #define MB2_HT(name) (MULTIBOOT2_HEADER_TAG_##name)
> > #define MB2_TT(name) (MULTIBOOT2_TA
On 16.09.2024 08:47, Juergen Gross wrote:
> The allocated size in xen_swiotlb_alloc_coherent() and
> xen_swiotlb_free_coherent() is calculated wrong for the case of
> XEN_PAGE_SIZE not matching PAGE_SIZE. Fix that.
>
> Fixes: 7250f422da04 ("xen-swiotlb: use actually allocated size on check
> phys
flight 187716 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187716/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187711
test-amd64-amd64-xl-qemuu-ws16-amd64
On 16.09.2024 09:50, Roger Pau Monné wrote:
> On Fri, Sep 13, 2024 at 02:38:14PM +0200, Jan Beulich wrote:
>> On 13.09.2024 09:59, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/time.c
>>> +++ b/xen/arch/x86/time.c
>>> @@ -1552,6 +1552,37 @@ static const char *__init
>>> wallclock_type_to_string(vo
On Fri, Sep 13, 2024 at 02:38:14PM +0200, Jan Beulich wrote:
> On 13.09.2024 09:59, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/time.c
> > +++ b/xen/arch/x86/time.c
> > @@ -1552,6 +1552,37 @@ static const char *__init
> > wallclock_type_to_string(void)
> > return "";
> > }
> >
> > +stati
On Mon, Sep 16, 2024 at 09:37:57AM +0300, Sergiy Kibrik wrote:
> Introduce config option X86_PMTIMER so that pmtimer driver can be disabled on
> systems that don't need it.
Same comment as in the VGA patch, you need to handle the user passing
X86_EMU_PM. It's not OK to just ignore the flag if the
On Sun, Sep 15, 2024 at 7:20 AM Jan Beulich wrote:
>
> On 10.09.2024 18:16, Frediano Ziglio wrote:
> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@ -231,6 +231,27 @@ __efi64_mb2_start:
> > /* VGA is not available on EFI platforms. */
> > movl $0,vga_
On Mon, Sep 16, 2024 at 09:37:16AM +0300, Sergiy Kibrik wrote:
> 12.09.24 12:14, Roger Pau Monné:
> > Shouldn't Xen report an error if a user attempts to create a domain
> > with X86_EMU_VGA set in emulation_flags, but stdvga has been built
> > time disabled?
>
> I'm afraid this can accidentally r
On Mon, Sep 16, 2024 at 09:30:11AM +0200, Takashi Iwai wrote:
> On Mon, 16 Sep 2024 09:24:42 +0200,
> Christoph Hellwig wrote:
> >
> > On Mon, Sep 16, 2024 at 09:16:58AM +0200, Takashi Iwai wrote:
> > > Yes, all those are really ugly hacks and have been already removed for
> > > 6.12. Let's hope
On Mon, 16 Sep 2024 09:24:42 +0200,
Christoph Hellwig wrote:
>
> On Mon, Sep 16, 2024 at 09:16:58AM +0200, Takashi Iwai wrote:
> > Yes, all those are really ugly hacks and have been already removed for
> > 6.12. Let's hope everything works as expected with it.
>
> The code currently in linux-nex
On Mon, Sep 16, 2024 at 09:16:58AM +0200, Takashi Iwai wrote:
> Yes, all those are really ugly hacks and have been already removed for
> 6.12. Let's hope everything works as expected with it.
The code currently in linux-next will not work as explained in my
previous mail, because it tries to side
On Thu, 12 Sep 2024 11:56:21 +0200,
Christoph Hellwig wrote:
>
> On Sat, Sep 07, 2024 at 11:38:50AM +0100, Andrew Cooper wrote:
> > Individual subsystems ought not to know or care about XENPV; it's a
> > layering violation.
>
> Agreed.
>
> > If the main APIs don't behave properly, then it probab
On 16.09.24 09:01, Jan Beulich wrote:
On 16.09.2024 08:59, Juergen Gross wrote:
On 16.09.24 08:56, Juergen Gross wrote:
On 16.09.24 08:50, Jan Beulich wrote:
On 16.09.2024 08:47, Juergen Gross wrote:
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -78,9 +78,15 @@ static inl
On 16.09.24 08:59, Jan Beulich wrote:
On 16.09.2024 08:56, Juergen Gross wrote:
On 16.09.24 08:50, Jan Beulich wrote:
On 16.09.2024 08:47, Juergen Gross wrote:
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -78,9 +78,15 @@ static inline int range_straddles_page_boundary(phy
On 16.09.2024 08:59, Juergen Gross wrote:
> On 16.09.24 08:56, Juergen Gross wrote:
>> On 16.09.24 08:50, Jan Beulich wrote:
>>> On 16.09.2024 08:47, Juergen Gross wrote:
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -78,9 +78,15 @@ static inline int
range_
On 16.09.24 08:56, Juergen Gross wrote:
On 16.09.24 08:50, Jan Beulich wrote:
On 16.09.2024 08:47, Juergen Gross wrote:
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -78,9 +78,15 @@ static inline int
range_straddles_page_boundary(phys_addr_t p, size_t size)
{
unsi
On 16.09.2024 08:56, Juergen Gross wrote:
> On 16.09.24 08:50, Jan Beulich wrote:
>> On 16.09.2024 08:47, Juergen Gross wrote:
>>> --- a/drivers/xen/swiotlb-xen.c
>>> +++ b/drivers/xen/swiotlb-xen.c
>>> @@ -78,9 +78,15 @@ static inline int
>>> range_straddles_page_boundary(phys_addr_t p, size_t si
75 matches
Mail list logo
