>>> On 08.02.19 at 18:02, wrote:
> On 2/8/19 6:44 PM, Jan Beulich wrote:
> On 08.02.19 at 17:30, wrote:
>>> On 2/8/19 5:50 PM, Jan Beulich wrote:
>>> On 08.02.19 at 15:00, wrote:
> /* If the alternate p2m state has changed, handle appropriately
> */
> -if (
Right, I now understand what you meant by removing "if ( ostate )" -
you'd like d->arch.altp2m_active to only be set _after_ the for, for the
enable, as well as for the disable case.
No, certainly not. Exactly because of ...
However, I wanted to keep both if()s to avoid another problem with
Hello,
Dongli Zhang, le lun. 11 févr. 2019 09:37:43 +0800, a ecrit:
> On 2/10/19 12:35 AM, Samuel Thibault wrote:
> > Hello,
> >
> > Hans van Kranenburg, le sam. 09 févr. 2019 17:01:55 +0100, a ecrit:
> >>> I have forwarded the original mail: all VM I/O get stuck, and thus the
> >>> VM becomes un
HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
on purpose (as it was originally supposed to cater to a in-guest
agent, and a domain pausing itself is not a good idea).
This can lead to domain crashes in the vmx_vmexit_handler() code
that checks if the guest has the ability to sw
>>> On 08.02.19 at 18:49, wrote:
> On Thu, Feb 07, 2019 at 05:21:28PM +, George Dunlap wrote:
>> On 2/5/19 1:38 PM, Roger Pau Monné wrote:
>> > On Tue, Feb 05, 2019 at 05:44:14AM -0700, Jan Beulich wrote:
>> >> When the assertion was introduced, MMIO wasn't handled by the
>> >> code correctly
>>> On 08.02.19 at 20:58, wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> This patch is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough.
>
> Signed
>>> On 09.02.19 at 18:10, wrote:
> Hello,
>
> On Tue, Feb 05, 2019 at 11:44:09AM +, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [Xen-devel] preparations for 4.10.3 and 4.9.4"):
>> > On 01.02.19 at 12:23, wrote:
>> > > For 4.10.3:
>> > >
>> > > https://lists.xen.org/archives/html/xen-deve
Hi all,
we have the community call for February coming up this Wednesday. My sincere
apologies, that I have not asked for agenda items last week. A current agenda
(primarily a skeleton) is available at
https://docs.google.com/document/d/15ZLzQcH794jufDZW1oNYVY2D12CnVqxQ-klFAqkd2bU/edit#headin
>>> On 11.02.19 at 10:13, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2150,13 +2150,13 @@ static bool_t vmx_is_singlestep_supported(void)
> return !!cpu_has_monitor_trap_flag;
> }
>
> -static void vmx_vcpu_update_eptp(struct vcpu *v)
> +static void vm
As XTF allows to write tests that interact with the hypervisor, we would like
to use this capability to implement micro benchmarks, so that we can measure
the performance impact of modifications to the hypervisor.
Signed-off-by: Norbert Manthey
---
build/common.mk | 2 +-
xtf-runner | 2 +-
Dear all,
I added a perf category to XTF, and added functions to measure time in the
guest. Finally, I added a first micro benchmark that measures the time to
call a specified hypercall, and print the average time the hypercall takes.
The added category should be useful to implement further micro
A first simple test is to call a hypercall in a tight loop. To measure
implementation aspects of the hypervisor, we picked a hypercall that
is not implemented and hence results in a no-op, namely the hypercall
mmuext_op with the command MMUEXT_MARK_SUPER.
Signed-off-by: Norbert Manthey
---
test
To measure how long a certain interaction takes, we need time
primitives. This commit introduces these primitives, so that
future tests can use the gettimeofday function to retrieve the
current time.
Signed-off-by: Paul Semel
Signed-off-by: Norbert Manthey
---
build/files.mk | 1 +
commo
The added function measure_performance allows to measure the run time
of a function, by computing the average time it takes to call that
function a given number of retries. The measured total time is returned
in nano seconds. Furthermore, the value is printed via printk in a
fixed format, to allow
Hi,
Am 07.01.2019 um 12:12 schrieb Patrick Beckmann:
> I just joined this list and am referring to
> https://lists.xenproject.org/archives/html/xen-devel/2018-12/msg00938.html
>
> We have experienced several crashes of a recent Debian 9 Dom0 on new
> hardware with Xen version "4.8.4+xsa273+shim
On 2/11/19 12:10 PM, Jan Beulich wrote:
On 11.02.19 at 10:13, wrote:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2150,13 +2150,13 @@ static bool_t vmx_is_singlestep_supported(void)
return !!cpu_has_monitor_trap_flag;
}
-static void vmx_vcpu_update_eptp(struc
On Fri, Feb 08, 2019 at 01:14:16PM +, Wei Liu wrote:
> On Fri, Feb 08, 2019 at 05:21:44AM +, osstest service owner wrote:
> > flight 133030 xen-unstable-smoke real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/133030/
> >
> > Failures and problems with tests :-(
Thanks for l
On Mon, Feb 11, 2019 at 02:47:48AM -0700, Jan Beulich wrote:
> >>> On 08.02.19 at 18:49, wrote:
> > On Thu, Feb 07, 2019 at 05:21:28PM +, George Dunlap wrote:
> >> On 2/5/19 1:38 PM, Roger Pau Monné wrote:
> >> > On Tue, Feb 05, 2019 at 05:44:14AM -0700, Jan Beulich wrote:
> >> >> When the ass
* Juergen Gross wrote:
> When limiting memory size via kernel parameter "mem=" this should be
> respected even in case of memory made accessible via a PCI card.
>
> Today this kind of memory won't be made usable in initial memory
> setup as the memory won't be visible in E820 map, but it might
>>> On 11.02.19 at 13:03, wrote:
> On Mon, Feb 11, 2019 at 02:47:48AM -0700, Jan Beulich wrote:
>> >>> On 08.02.19 at 18:49, wrote:
>> > On Thu, Feb 07, 2019 at 05:21:28PM +, George Dunlap wrote:
>> >> On 2/5/19 1:38 PM, Roger Pau Monné wrote:
>> >> > On Tue, Feb 05, 2019 at 05:44:14AM -0700,
On 11/02/2019 13:06, Ingo Molnar wrote:
>
> * Juergen Gross wrote:
>
>> When limiting memory size via kernel parameter "mem=" this should be
>> respected even in case of memory made accessible via a PCI card.
>>
>> Today this kind of memory won't be made usable in initial memory
>> setup as the
* Juergen Gross wrote:
> > If PCI devices had physical mmio memory areas above this range, we'd
> > still expect them to work - the option was really only meant to limit
> > RAM.
>
> No, in this case it seems to be real RAM added via PCI. The RAM is
> initially present in the E820 map, but t
On Tue, 2019-01-08 at 09:25 -0700, Jan Beulich wrote:
> > > > On 19.12.18 at 19:52, wrote:
> >
> > @@ -796,7 +787,7 @@ struct xen_domctl_gdbsx_domstatus {
> > * EXDEV - guest has PoD enabled
> > * EBUSY - guest has or had paging enabled, ring buffer still
> > active
> > */
> > -#define XE
On 11/02/2019 13:23, Ingo Molnar wrote:
>
> * Juergen Gross wrote:
>
>>> If PCI devices had physical mmio memory areas above this range, we'd
>>> still expect them to work - the option was really only meant to limit
>>> RAM.
>>
>> No, in this case it seems to be real RAM added via PCI. The RAM
flight 132990 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132990/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 133027 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133027/
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
On 2/6/19 16:10, Jan Beulich wrote:
On 06.02.19 at 15:09, wrote:
>> From: Norbert Manthey
>>
>> In the early steps of compilation, the asm header files are created, such
>> as include/asm-$(TARGET_ARCH)/asm-offsets.h. These files depend on the
>> assembly file arch/$(TARGET_ARCH)/asm-offsets
flight 133093 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133093/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
flight 133134 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133134/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-armhf 6 xen
On Fri, Feb 08, 2019 at 08:36:54PM +0100, Sander Eikelenboom wrote:
> On 08/02/2019 17:47, Roger Pau Monné wrote:
> > On Fri, Feb 08, 2019 at 05:15:22PM +0100, Sander Eikelenboom wrote:
> >> On 08/02/2019 16:10, Roger Pau Monné wrote:
> >>> On Fri, Jan 25, 2019 at 07:44:40PM +0100, Sander Eikelenbo
>>> On 11.02.19 at 04:59, wrote:
> On Fri, Feb 08, 2019 at 04:41:19AM -0700, Jan Beulich wrote:
> On 28.01.19 at 08:06, wrote:
>>> @@ -208,6 +210,58 @@ static void microcode_fini_cpu(unsigned int cpu)
>>> spin_unlock(µcode_mutex);
>>> }
>>>
>>> +/* Save a ucode patch to the global cac
>>> On 11.02.19 at 06:40, wrote:
> On Fri, Feb 08, 2019 at 09:29:32AM -0700, Jan Beulich wrote:
> On 28.01.19 at 08:06, wrote:
>>> +/*
>>> + * Initiate an update on all processors which don't have an online
>>> sibling
>>> + * thread with a lower thread id. Other sibling threads
flight 133106 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133106/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
flight 133126 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133126/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2a784a2cc356df5a8958afe88bc7e844dc0fb7cc
baseline version:
ovmf 7a90895306acbf970de87
On 11/02/2019 14:23, Jan Beulich wrote:
On 11.02.19 at 06:40, wrote:
>> On Fri, Feb 08, 2019 at 09:29:32AM -0700, Jan Beulich wrote:
>> On 28.01.19 at 08:06, wrote:
+/*
+ * Initiate an update on all processors which don't have an online
sibling
+ * thread
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-shadow
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.gi
On 2/11/19 12:57 PM, Razvan Cojocaru wrote:
On 2/11/19 12:10 PM, Jan Beulich wrote:
On 11.02.19 at 10:13, wrote:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2150,13 +2150,13 @@ static bool_t vmx_is_singlestep_supported(void)
return !!cpu_has_monitor_trap_flag;
flight 133111 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133111/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
On 11/02/2019 14:07, Norbert Manthey wrote:
> On 2/6/19 16:10, Jan Beulich wrote:
> On 06.02.19 at 15:09, wrote:
>>> From: Norbert Manthey
>>>
>>> In the early steps of compilation, the asm header files are created, such
>>> as include/asm-$(TARGET_ARCH)/asm-offsets.h. These files depend on t
flight 133114 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133114/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
On Mon, Feb 11, 2019 at 02:35:30PM +0100, Juergen Gross wrote:
> On 11/02/2019 14:23, Jan Beulich wrote:
> On 11.02.19 at 06:40, wrote:
> >> On Fri, Feb 08, 2019 at 09:29:32AM -0700, Jan Beulich wrote:
> >> On 28.01.19 at 08:06, wrote:
> +/*
> + * Initiate an update on
flight 133149 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133149/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
>>> On 11.02.19 at 14:35, wrote:
> On 11/02/2019 14:23, Jan Beulich wrote:
> On 11.02.19 at 06:40, wrote:
>>> On Fri, Feb 08, 2019 at 09:29:32AM -0700, Jan Beulich wrote:
>>> On 28.01.19 at 08:06, wrote:
> +/*
> + * Initiate an update on all processors which don't have an
On 11/02/2019 14:16, Roger Pau Monné wrote:
> On Fri, Feb 08, 2019 at 08:36:54PM +0100, Sander Eikelenboom wrote:
>> On 08/02/2019 17:47, Roger Pau Monné wrote:
>>> On Fri, Feb 08, 2019 at 05:15:22PM +0100, Sander Eikelenboom wrote:
On 08/02/2019 16:10, Roger Pau Monné wrote:
> On Fri, Jan
>>> On 11.02.19 at 14:46, wrote:
> On 2/11/19 12:57 PM, Razvan Cojocaru wrote:
>> On 2/11/19 12:10 PM, Jan Beulich wrote:
>> On 11.02.19 at 10:13, wrote:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2150,13 +2150,13 @@ static bool_t vmx_is_singlestep_su
On Fri, Feb 8, 2019 at 10:52 AM Souptick Joarder wrote:
>
> On Thu, Feb 7, 2019 at 10:17 PM Matthew Wilcox wrote:
> >
> > On Thu, Feb 07, 2019 at 09:19:47PM +0530, Souptick Joarder wrote:
> > > Just thought to take opinion for documentation before placing it in v3.
> > > Does it looks fine ?
> >
On 2/11/19 6:59 PM, Jan Beulich wrote:
>>> Thanks for noticing, actually this appears to invalidate the whole
>>> purpose of the patch (I should have tested this more before sumbitting
>>> V3, sorry).
>>>
>>> The whole point of the new boolean is to have p2m assigned an altp2m
>>> regardless of
Hello,
The following series contains fixes that should be considered for 4.12.
I'm not sure whether patches 5, 6 and 7 should be aimed at 4.12, they
contain changes to the p2m code that could affect HVM guests. Note that
without those changes a PVH dom0 running on AMD hardware will be unable
to c
The p2m and iommu mapping code always had the requirement that
addresses and orders must be aligned when populating the p2m or the
iommu page tables.
PVH dom0 builder didn't take this requirement into account, and can
call into the p2m/iommu mapping helpers with addresses and orders that
are not a
So that the specific handling can be removed from
atomic_write_ept_entry and be shared with npt and shadow code.
This commit also removes the check that prevent non-ept PVH dom0 from
mapping foreign pages.
Signed-off-by: Roger Pau Monné
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
There have been several reports of the dom0 builder running out of
memory when building a PVH dom0 without having specified a dom0_mem
value. Print a warning message if dom0_mem is not set when booting in
PVH mode.
This is a temporary workaround until accounting for internal memory
required by Xen
Current npt and shadow code to get an entry will always return
INVALID_MFN for foreign entries. Allow to return the entry mfn for
foreign entries, like it's done for grant table entries.
Signed-off-by: Roger Pau Monné
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xe
The assert was originally added to make sure that higher order
regions (> PAGE_ORDER_4K) could not be used to bypass the
mmio_ro_ranges check performed by p2m_type_to_flags.
This however is already checked in set_mmio_p2m_entry, which makes
sure that higher order mappings don't overlap with mmio_r
So that the iommu is initialized before populating the p2m, and
entries added get the corresponding iommu page table entries if
required. This requires splitting the current pvh_setup_p2m into two
different functions. One that crafts dom0 physmap and sets the paging
allocation, and another one that
So that it can be shared by both ept, npt and shadow code, instead of
duplicating it.
No change in functionality intended.
Signed-off-by: Roger Pau Monné
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: Paul Durrant
---
Changes since
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-ovmf-amd64
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-trad
flight 133127 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133127/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
flight 133129 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133129/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-arm64-xsm
flight 133154 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133154/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
On 11/02/2019 18:46, Roger Pau Monne wrote:
> Hello,
>
> The following series contains fixes that should be considered for 4.12.
>
> I'm not sure whether patches 5, 6 and 7 should be aimed at 4.12, they
> contain changes to the p2m code that could affect HVM guests. Note that
> without those chan
On 2/11/19 2:37 AM, Dongli Zhang wrote:
>
> On 2/10/19 12:35 AM, Samuel Thibault wrote:
>>
>> Hans van Kranenburg, le sam. 09 févr. 2019 17:01:55 +0100, a ecrit:
I have forwarded the original mail: all VM I/O get stuck, and thus the
VM becomes unusable.
>>>
>>> These are in many cases th
Hans van Kranenburg, le lun. 11 févr. 2019 22:59:11 +0100, a ecrit:
> On 2/11/19 2:37 AM, Dongli Zhang wrote:
> >
> > On 2/10/19 12:35 AM, Samuel Thibault wrote:
> >>
> >> Hans van Kranenburg, le sam. 09 févr. 2019 17:01:55 +0100, a ecrit:
> I have forwarded the original mail: all VM I/O get
flight 133161 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133161/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
flight 133137 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133137/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 9e141fd88fe790e076980d25cc8373b9c880efb8
baseline version:
freebsd 50ac923f6c3
flight 133170 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133170/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
Hi all,
This version of the series introduces two macros to compare and subtract
linker symbols. Note that it has been suggested on the list to add type
checking inside the macros, but that is not done in this version of the
series.
Cheers,
Stefano
The following changes since commit 808cff4c2a
uintptr_t should be "unsigned long" -- same size as a pointer.
Introduce the new type "ptrdiff_t" which is defined as the signed
integer type of the result of subtracting two pointers.
Signed-off-by: Stefano Stabellini
CC: jbeul...@suse.com
CC: andrew.coop...@citrix.com
CC: julien.gr...@arm.com
Use SYMBOLS_SUBTRACT and SYMBOLS_COMPARE in cases of comparisons and
subtractions of:
_start, _end, __2M_rwdata_start, __2M_rwdata_end, _stext, _etext,
__end_vpci_array, __start_vpci_array, _stextentry, _etextentry,
__trampoline_rel_start, __trampoline_rel_stop, __trampoline_seg_start,
__trampolin
Introduce two macros meant used everywhere symbols such as _stext and
_etext are compared or subtracted in the code.
They are needed because the C standard forbids for both comparisons and
substraction (see C Standard, 6.5.6 [ISO/IEC 9899:2011] and [1]) between
pointers pointing to different objec
Use SYMBOLS_SUBTRACT and SYMBOLS_COMPARE in cases of comparisons and
subtractions of:
_start, _end, __init_begin, __init_end, _stext, _etext,
__alt_instructions, __alt_instructions_end, __per_cpu_start,
__per_cpu_data_end, _splatform, _eplatform, _sdevice, _edevice,
_asdevice, _aedevice.
as by th
Use SYMBOLS_SUBTRACT and SYMBOLS_COMPARE in cases of comparisons and
subtractions of:
_start, _end, _stext, _etext, _srodata, _erodata, _sinittext,
_einittext, __note_gnu_build_id_start, __note_gnu_build_id_end,
__lock_profile_start, __lock_profile_end, __initcall_start,
__initcall_end, __presmp_i
flight 133173 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133173/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
On 02/12/2019 06:10 AM, Samuel Thibault wrote:
> Hans van Kranenburg, le lun. 11 févr. 2019 22:59:11 +0100, a ecrit:
>> On 2/11/19 2:37 AM, Dongli Zhang wrote:
>>>
>>> On 2/10/19 12:35 AM, Samuel Thibault wrote:
Hans van Kranenburg, le sam. 09 févr. 2019 17:01:55 +0100, a ecrit:
>>
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-amd64-pvgrub
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional
flight 133178 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133178/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, February 6, 2019 6:24 PM
>
> set_mmio_p2m_entry() may fail, in particular with -ENOMEM. Don't ignore
> such an error, but instead cause domain creation to fail in such a case.
>
> Signed-off-by: Jan Beulich
Acked-by: Kevin Tian
> From: Juergen Gross [mailto:jgr...@suse.com]
> Sent: Saturday, February 2, 2019 12:30 AM
>
> Commit 32a5ea00ec75ef53e ("IOMMU/x86: remove indirection from
> certain
> IOMMU hook accesses") introduced iommu_ops initialized at boot time
> with data declared as __initconstrel.
>
> On Intel systems
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-pair
testid xen-boot/dst_host
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditiona
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-pair
testid xen-boot/src_host
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditiona
>>> On 11.02.19 at 18:21, wrote:
> On 2/11/19 6:59 PM, Jan Beulich wrote:
Thanks for noticing, actually this appears to invalidate the whole
purpose of the patch (I should have tested this more before sumbitting
V3, sorry).
The whole point of the new boolean is to have p
80 matches
Mail list logo
