Hello Juergen,
Please note that this patch will clash with [1].
On 28.05.19 13:32, Juergen Gross wrote:
vcpu->last_run_time is primarily used by sched_credit, so move it to
struct sched_unit, too.
`last_run_time` is moved to credit privates as for current staging.
[1]
https://xenbits.xen.o
Hi Andrii,
On 13.06.19 09:18, Andrii Anisov wrote:
Hello Juergen,
Please note that this patch will clash with [1].
On 28.05.19 13:32, Juergen Gross wrote:
vcpu->last_run_time is primarily used by sched_credit, so move it to
struct sched_unit, too.
`last_run_time` is moved to credit privates
On 13.06.19 10:29, Juergen Gross wrote:
Thanks for the heads up, but I've rebased already. :-)
Oh, great. I'm just wondering if you put it already on your github?
I'm playing with scheduling on my site, and I have a strong feeling I should be
based on your series ;)
--
Sincerely,
Andrii Ani
Hi Stefano,
On 6/12/19 11:25 PM, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
Currently, the virtual address of the 3rd level page-tables is obtained
using mfn_to_virt().
On Arm32, mfn_to_virt can only work on xenheap page. While in practice
all the page-tables updated wi
Hi Stefano,
On 6/12/19 11:52 PM, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
Currently, xen_pt_update_entry() is only able to update the region covered
by xen_second (i.e 0 to 0x7fff).
Because of the restriction we end to have multiple functions in mm.c
modifying the
Hi Stefano,
On 6/12/19 11:33 PM, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
{set, clear}_fixmap() are currently open-coding update to the Xen
page-tables. This can be avoided by using the generic helpers
map_pages_to_xen() and destroy_xen_mappings().
Both function are n
On 13.06.19 09:34, Andrii Anisov wrote:
On 13.06.19 10:29, Juergen Gross wrote:
Thanks for the heads up, but I've rebased already. :-)
Oh, great. I'm just wondering if you put it already on your github?
github.com/jgross1/xen sched-v1-rebase
Only compile tested on x86 up to now, but rebas
чт, 13 черв. 2019 о 11:39 Juergen Gross пише:
> github.com/jgross1/xen sched-v1-rebase
>
> Only compile tested on x86 up to now, but rebase was rather easy.
>
Cool, will take it and check for ARM.
Thank you.
Sincerely,
Andrii Anisov.
___
Xen-devel mai
Hi Stefano,
On 6/12/19 11:41 PM, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
set_pte_flags_on_range() is yet another function that will open-code
update to a specific range in the Xen page-tables. It can be completely
dropped by using either modify_xen_mappings() or destr
On 26.09.2018 19:47, George Dunlap wrote:
> From: Isaila Alexandru
>
> This patch adds access control for NPT mode.
>
> There aren’t enough extra bits to store the access rights in the NPT p2m
> table, so we add a radix tree to store extra information.
>
> For efficiency:
> - Only allocate
Please review this patch.
Am Tue, 29 May 2018 14:06:48 +0200
schrieb Olaf Hering :
> The function read_vtpmblk uses printf(3), but stdio.h is not included
> in this file. This results in a warning from gcc-7:
>
> vtpmblk.c: In function 'read_vtpmblk':
> vtpmblk.c:322:7: warning: implicit declara
Hi Stefano,
On 08/06/2019 01:17, Stefano Stabellini wrote:
On Wed, 5 Jun 2019, Julien Grall wrote:
On 05/06/2019 00:11, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
The function create_xen_entries() may be called concurrently. For
instance, while the vmap allocation is p
Hi,
On 14/05/2019 13:24, Julien Grall wrote:
This is the second part of the boot/memory rework for Xen on Arm. This
part contains mostly clean-up & fixes found during the rework.
The first part of the rework is "xen/arm: TLB flush helpers rework" [1].
For convenience, I provided a branch with
Jan,
On 12.06.19 10:27, Jan Beulich wrote:
Well, my point here is to left it as is, maybe add more documentation. If
one likes shooting his leg, we should only care about avoiding ricochet harms
hypervisor or other guests.
If you disagree, please suggest your interaction model, I'll be happy to
Jan,
On 11.06.19 13:22, Andrii Anisov wrote:
Hello Jan,
On 11.06.19 12:10, Jan Beulich wrote:
Except when there's no need for KPTI in the guest in the first place,
as is the case for x86-64 PV guests. I think this is worthwhile clarifying.
I am not sure what is your point here. At least on A
Jan, Julien,
On 11.06.19 12:10, Jan Beulich wrote:
At the very least such loops want a cpu_relax() in their bodies.
But this being on a hypercall path - are there theoretical guarantees
that a guest can't abuse this to lock up a CPU?
Hmmm, I suggested this but it looks like a guest may call the
>>> On 13.06.19 at 14:17, wrote:
> On 12.06.19 10:27, Jan Beulich wrote:
>>> Well, my point here is to left it as is, maybe add more documentation. If
>>> one likes shooting his leg, we should only care about avoiding ricochet
> harms
>>> hypervisor or other guests.
>>> If you disagree, please su
>>> On 13.06.19 at 14:21, wrote:
> On 11.06.19 13:22, Andrii Anisov wrote:
>> On 11.06.19 12:10, Jan Beulich wrote:
> Except when there's no need for KPTI in the guest in the first place,
> as is the case for x86-64 PV guests. I think this is worthwhile
> clarifying.
I am no
flight 137639 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137639/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 137269
test-amd64-amd64-xl-qemuu-win7-amd64 17
>>> On 13.06.19 at 14:32, wrote:
> Jan, Julien,
>
> On 11.06.19 12:10, Jan Beulich wrote:
At the very least such loops want a cpu_relax() in their bodies.
But this being on a hypercall path - are there theoretical guarantees
that a guest can't abuse this to lock up a CPU?
>>> Hmmm,
Hi Jan,
On 13/06/2019 13:41, Jan Beulich wrote:
On 13.06.19 at 14:32, wrote:
Jan, Julien,
On 11.06.19 12:10, Jan Beulich wrote:
At the very least such loops want a cpu_relax() in their bodies.
But this being on a hypercall path - are there theoretical guarantees
that a guest can't abuse this
>>> On 13.06.19 at 14:48, wrote:
> Hi Jan,
>
> On 13/06/2019 13:41, Jan Beulich wrote:
> On 13.06.19 at 14:32, wrote:
>>> Jan, Julien,
>>>
>>> On 11.06.19 12:10, Jan Beulich wrote:
>> At the very least such loops want a cpu_relax() in their bodies.
>> But this being on a hypercall pa
It is only of limited use to check the full accumulated 32-bit value,
because the high halves are the cluster ID. What needs to be non-zero is
the bit map at the bottom, or else APIC errors will result.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/genapic/x2apic.c
+++ b/xen/arch/x86/genapic/x2a
On 13/06/2019 14:06, Jan Beulich wrote:
> It is only of limited use to check the full accumulated 32-bit value,
> because the high halves are the cluster ID. What needs to be non-zero is
> the bit map at the bottom, or else APIC errors will result.
>
> Signed-off-by: Jan Beulich
I take it you loc
Hi Jan,
On 13/06/2019 13:58, Jan Beulich wrote:
On 13.06.19 at 14:48, wrote:
Hi Jan,
On 13/06/2019 13:41, Jan Beulich wrote:
On 13.06.19 at 14:32, wrote:
Jan, Julien,
On 11.06.19 12:10, Jan Beulich wrote:
At the very least such loops want a cpu_relax() in their bodies.
But this being on
Despite the title this is actually all AMD IOMMU side work; all x86
side adjustments have already been carried out.
If in doubt, the series is assumed to go on top of
AMD/IOMMU: initialize IRQ tasklet only once [1]
AMD/IOMMU: revert "amd/iommu: assign iommu devices to Xen" [2]
AMD/IOMMU: don't "a
>>> On 13.06.19 at 15:11, wrote:
> On 13/06/2019 14:06, Jan Beulich wrote:
>> It is only of limited use to check the full accumulated 32-bit value,
>> because the high halves are the cluster ID. What needs to be non-zero is
>> the bit map at the bottom, or else APIC errors will result.
>>
>> Signe
At the same time restrict its scope to just the single source file
actually using it, and abstract accesses by introducing a union of
pointers. (A union of the actual table entries is not used to make it
impossible to [wrongly, once the 128-bit form gets added] perform
pointer arithmetic / array ac
Also introduce a field in struct amd_iommu caching the most recently
written control register. All writes should now happen exclusively from
that cached value, such that it is guaranteed to be up to date.
Take the opportunity and add further fields. Also convert a few boolean
function parameters t
This also takes care of several of the shift values wrongly having been
specified as hex rather than dec.
Take the opportunity and add further fields.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu_detect.c
+++ b/xen/drivers/passthrough/amd/iommu_detect.c
@@ -60,43 +60,72 @@
This is in preparation of actually enabling x2APIC mode, which requires
this wider IRTE format to be used.
A specific remark regarding the first hunk changing
amd_iommu_ioapic_update_ire(): This bypass was introduced for XSA-36,
i.e. by 94d4a1119d ("AMD,IOMMU: Clean up old entries in remapping
tab
Mapping the MMIO space and obtaining feature information needs to happen
slightly earlier, such that for x2APIC support we can set XTEn prior to
calling amd_iommu_update_ivrs_mapping_acpi() and
amd_iommu_setup_ioapic_remapping().
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu
Early enabling (to enter x2APIC mode) requires deferring of the IRQ
setup. Code to actually do that setup in the x2APIC case will get added
subsequently.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -814,7 +814,6 @@ s
In order to be able to express all possible destinations we need to make
use of this non-MSI-capability based mechanism. The new IRQ controller
structure can re-use certain MSI functions, though.
For now general and PPR interrupts still share a single vector, IRQ, and
hence handler.
Signed-off-by
In order for the CPUs to use x2APIC mode, the IOMMU(s) first need to be
switched into suitable state.
The post-AP-bringup IRQ affinity adjustment is done also for the non-
x2APIC case.
Signed-off-by: Jan Beulich
---
TBD: Instead of the system_state check in iov_enable_xt() the function
coul
While for 32-bit IRTEs I think we can safely continue to assume that the
writes will translate to a single MOV, the use of CMPXCHG16B is more
heavy handed than necessary for the 128-bit form, and the flushing
didn't get done along the lines of what the specification says. Mark
entries to be updated
>>> On 13.06.19 at 15:14, wrote:
> On 13/06/2019 13:58, Jan Beulich wrote:
> On 13.06.19 at 14:48, wrote:
>>> On 13/06/2019 13:41, Jan Beulich wrote:
>>> On 13.06.19 at 14:32, wrote:
> On 11.06.19 12:10, Jan Beulich wrote:
At the very least such loops want a cpu_relax() in t
Remove myself as vm_event maintaner, add Alexandru and Petre as
Bitdefender vm_event maintainers.
Signed-off-by: Razvan Cojocaru
---
Re-sent to add Tamas', Petre's and Alexandru's addresses.
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAIN
On Wed, Jun 12, 2019 at 01:38:31AM -0600, Jan Beulich wrote:
On 11.06.19 at 18:04, wrote:
>> On Tue, Jun 11, 2019 at 08:46:04PM +0800, Chao Gao wrote:
>>> On Wed, Jun 05, 2019 at 08:53:46AM -0600, Jan Beulich wrote:
>>> >
>>> >> @@ -307,8 +303,7 @@ static int apply_microcode(const struct
>>>
flight 137641 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137641/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16
guest-start/debianhvm.repeat fail REGR. vs. 136
>>> On 13.06.19 at 16:05, wrote:
> On Wed, Jun 12, 2019 at 01:38:31AM -0600, Jan Beulich wrote:
> On 11.06.19 at 18:04, wrote:
>>> On Tue, Jun 11, 2019 at 08:46:04PM +0800, Chao Gao wrote:
On Wed, Jun 05, 2019 at 08:53:46AM -0600, Jan Beulich wrote:
>
>> @@ -307,8 +303,7 @@ sta
>>> On 07.06.19 at 11:22, wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -420,12 +420,12 @@ static void disable_c1_ramping(void)
> nr_nodes = ((pci_conf_read32(0, 0, 0x18, 0x0, 0x60)>>4)&0x07)+1;
> for (node = 0; node < nr_nodes; node++) {
> /*
On Wed, Jun 05, 2019 at 04:24:06PM +0200, Juergen Gross wrote:
> On 05.06.19 16:13, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jun 04, 2019 at 03:41:40PM -0400, Boris Ostrovsky wrote:
> > > On 6/4/19 12:51 PM, Stefano Stabellini wrote:
> > > > On Mon, 3 Jun 2019, Boris Ostrovsky wrote:
> > > > > On 6
>>> On 07.06.19 at 11:22, wrote:
> This reduces the number of parameters of the function to two, and
> simplifies some of the calling sites.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenp
>>> On 07.06.19 at 11:22, wrote:
> @@ -817,7 +811,7 @@ static u64 read_pci_mem_bar(u16 seg, u8 bus, u8 slot, u8
> func, u8 bir, int vf)
> if ( ++bir >= limit )
> return 0;
> return addr + disp +
> - ((u64)pci_conf_read32(seg, bus, slot, func,
> +
Hi Jan,
On 13/06/2019 14:40, Jan Beulich wrote:
On 13.06.19 at 15:14, wrote:
I am not asking you to spend a lot of time on it. But if you have a gut feeling
this can be done, then a little help would be extremely useful...
... I thought I had already outlined a model: Allow cross-vCPU update
On 5/29/18 8:06 AM, Olaf Hering wrote:
The function read_vtpmblk uses printf(3), but stdio.h is not included
in this file. This results in a warning from gcc-7:
vtpmblk.c: In function 'read_vtpmblk':
vtpmblk.c:322:7: warning: implicit declaration of function 'printf'
[-Wimplicit-function-declar
>>> On 11.06.19 at 19:01, wrote:
> @@ -77,6 +76,7 @@ static void update_reference_tsc(struct domain *d, bool
> initialize)
> * ticks per 100ns shifted left by 64.
> */
> p->TscScale = ((1ul << 32) / d->arch.tsc_khz) << 32;
> +p->TscOffset = trc->off;
> smp_wmb();
Ev
On Thu, Jun 13, 2019 at 08:08:46AM -0600, Jan Beulich wrote:
On 13.06.19 at 16:05, wrote:
>> On Wed, Jun 12, 2019 at 01:38:31AM -0600, Jan Beulich wrote:
>> On 11.06.19 at 18:04, wrote:
On Tue, Jun 11, 2019 at 08:46:04PM +0800, Chao Gao wrote:
> On Wed, Jun 05, 2019 at 08:53:46A
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 13 June 2019 15:47
> To: Paul Durrant
> Cc: Andrew Cooper ; Roger Pau Monne
> ; xen-devel de...@lists.xenproject.org>; WeiLiu
> Subject: Re: [PATCH] viridian: unify time sources
>
> >>> On 11.06.19 at 19:01, w
On 13.06.19 16:23, Konrad Rzeszutek Wilk wrote:
On Wed, Jun 05, 2019 at 04:24:06PM +0200, Juergen Gross wrote:
On 05.06.19 16:13, Konrad Rzeszutek Wilk wrote:
On Tue, Jun 04, 2019 at 03:41:40PM -0400, Boris Ostrovsky wrote:
On 6/4/19 12:51 PM, Stefano Stabellini wrote:
On Mon, 3 Jun 2019, Bor
Could we include following commit?
Subject: libxl: keep assigned pci devices across domain reboots
From: Roger Pau Monne roger@citrix.com Thu Sep 20 12:40:25 2018 +0200
Date: Fri Sep 21 17:13:00 2018 +0100:
Git: 99a9c70583bd6dc2555b242353821a32cf1948a9
Thanks,
Charles
___
On Thu, Jun 13, 2019 at 8:01 AM Razvan Cojocaru
wrote:
>
> Remove myself as vm_event maintaner, add Alexandru and Petre as
> Bitdefender vm_event maintainers.
>
> Signed-off-by: Razvan Cojocaru
Acked-by: Tamas K Lengyel
___
Xen-devel mailing list
Xen
On Wed, Sep 26, 2018 at 10:49 AM George Dunlap wrote:
>
> From: Isaila Alexandru
>
> This patch adds access control for NPT mode.
>
> There aren’t enough extra bits to store the access rights in the NPT p2m
> table, so we add a radix tree to store extra information.
>
> For efficiency:
> - Only
On 6/13/19 6:19 PM, Tamas Lengyel wrote:
On Wed, Sep 26, 2018 at 10:49 AM George Dunlap wrote:
From: Isaila Alexandru
This patch adds access control for NPT mode.
There aren’t enough extra bits to store the access rights in the NPT p2m
table, so we add a radix tree to store extra informatio
flight 137716 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137716/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Thu, Jun 13, 2019 at 08:08:46AM -0600, Jan Beulich wrote:
> >>> On 13.06.19 at 16:05, wrote:
> > On Wed, Jun 12, 2019 at 01:38:31AM -0600, Jan Beulich wrote:
> > On 11.06.19 at 18:04, wrote:
> >>> On Tue, Jun 11, 2019 at 08:46:04PM +0800, Chao Gao wrote:
> On Wed, Jun 05, 2019 at 08:5
On Thu, 13 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 6/12/19 11:25 PM, Stefano Stabellini wrote:
> > On Tue, 14 May 2019, Julien Grall wrote:
> > > Currently, the virtual address of the 3rd level page-tables is obtained
> > > using mfn_to_virt().
> > >
> > > On Arm32, mfn_to_virt can onl
On Thu, 13 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 6/12/19 11:52 PM, Stefano Stabellini wrote:
> > On Tue, 14 May 2019, Julien Grall wrote:
> > > Currently, xen_pt_update_entry() is only able to update the region covered
> > > by xen_second (i.e 0 to 0x7fff).
> > >
> > > Because of
On Thu, 13 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 6/12/19 11:41 PM, Stefano Stabellini wrote:
> > On Tue, 14 May 2019, Julien Grall wrote:
> > > set_pte_flags_on_range() is yet another function that will open-code
> > > update to a specific range in the Xen page-tables. It can be compl
On Thu, 13 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 6/12/19 11:33 PM, Stefano Stabellini wrote:
> > On Tue, 14 May 2019, Julien Grall wrote:
> > > {set, clear}_fixmap() are currently open-coding update to the Xen
> > > page-tables. This can be avoided by using the generic helpers
> > > m
> >
> > #2 patch says:
> >
> > "> To be symmetric with setting the flag only after having made the
> > region
> > > contiguous, and to avoid (perhaps just theoretical) races, wouldn't
> > it be
> > > better to clear the flag before calling
> > xen_destroy_contiguous_region()?
> >
Hi Stefano,
On 13/06/2019 19:51, Stefano Stabellini wrote:
> On Thu, 13 Jun 2019, Julien Grall wrote:
>> On 6/12/19 11:33 PM, Stefano Stabellini wrote:
>>> On Tue, 14 May 2019, Julien Grall wrote:
> I think the basic principle is that with BUG_ON is "easy" for a guest to
> be able to trigger it, p
On 13/06/2019 19:04, Stefano Stabellini wrote:
> On Thu, 13 Jun 2019, Julien Grall wrote:
>
> Yes, on second thought, a BUG_ON is fine here. The risk is only when the
> BUG_ON could somehow be trigger by guest behavior, which is not the case
> here.
Agreed. I think we are safe to use BUG_ON(...
Hi Stefano,
On 13/06/2019 18:59, Stefano Stabellini wrote:
> On Thu, 13 Jun 2019, Julien Grall wrote: + * Return values:
+ * XEN_TABLE_MAP_FAILED: Either read_only was set and the entry
+ * was empty, or allocating a new page failed.
+ * XEN_TABLE_NORMAL_PAGE: next level map
flight 137654 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137654/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs.
127792
test-am
On Thu, 13 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 13/06/2019 19:51, Stefano Stabellini wrote:
> > On Thu, 13 Jun 2019, Julien Grall wrote:
> >> On 6/12/19 11:33 PM, Stefano Stabellini wrote:
> >>> On Tue, 14 May 2019, Julien Grall wrote:
> > I think the basic principle is that with BUG
On Thu, 13 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 13/06/2019 18:59, Stefano Stabellini wrote:
> > On Thu, 13 Jun 2019, Julien Grall wrote: + * Return values:
> + * XEN_TABLE_MAP_FAILED: Either read_only was set and the entry
> + * was empty, or allocating a new page fa
flight 137663 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137663/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 133596
build-amd64-pre
flight 137664 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137664/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 132889
build-amd64-pre
The condition in xen_swiotlb_free_coherent() for deciding whether to
call xen_destroy_contiguous_region() is wrong: in case the region to
be freed is not contiguous calling xen_destroy_contiguous_region() is
the wrong thing to do: it would result in inconsistent mappings of
multiple PFNs to the sam
range_straddles_page_boundary() is open coding several macros from
include/xen/page.h. Use those instead. Additionally there is no need
to have check_pages_physically_contiguous() as a separate function as
it is used only once, so merge it into range_straddles_page_boundary().
Signed-off-by: Juerg
Instead of always calling xen_destroy_contiguous_region() in case the
memory is DMA-able for the used device, do so only in case it has been
made DMA-able via xen_create_contiguous_region() before.
This will avoid a lot of xen_destroy_contiguous_region() calls for
64-bit capable devices.
As the m
While hunting an issue in swiotlb-xen I stumbled over a wrong test
and found some areas for improvement.
Juergen Gross (3):
xen/swiotlb: fix condition for calling xen_destroy_contiguous_region()
xen/swiotlb: simplify range_straddles_page_boundary()
xen/swiotlb: remember having called xen_cre
74 matches
Mail list logo
