branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-pvshim
testid guest-start
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
On Tue, Aug 21, 2018 at 12:44:12PM +0200, David Hildenbrand wrote:
> This is the same approach as in the first RFC, but this time without
> exporting device_hotplug_lock (requested by Greg) and with some more
> details and documentation regarding locking. Tested only on x86 so far.
Hi David,
I
flight 127044 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127044/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1e57188216b1bf8de3473a0e03e422815f8f53d6
baseline version:
ovmf
flight 127073 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127073/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 126996
Tests which
This run is configured for baseline tests only.
flight 75150 xen-4.7-testing real [real]
http://osstest.xensource.com/osstest/logs/75150/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-raw 10 debian-di-install
This run is configured for baseline tests only.
flight 75149 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75149/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75145
flight 127066 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127066/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 126996
Tests which
flight 127012 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127012/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-shadow 20 guest-start/debian.repeat fail REGR. vs. 126854
Tests which did
On 08/31/2018 09:39 PM, Julien Grall wrote:
Hi,
tl;dr: I think we don't disagree on the usefulness of this change in
general, so let's just change the commit towards something like:
Update the Xen image header to match the newest Linux kernel definition.
This allows to specify some relaxed
flight 127019 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127019/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs. 124248
Tests which
flight 127006 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127006/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125183
test-amd64-i386-xl-qemut-win7-amd64 17
flight 127059 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127059/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 126996
Tests which
On 31/08/2018 19:04, André Przywara wrote:
On 08/31/2018 06:14 PM, Julien Grall wrote:
Hi,
Hi,
On 08/31/2018 06:01 PM, Amit Singh Tomar wrote:
While porting XEN on Amlogic SoC we found that in absence of
image_size field of XEN image header, bootloader(U-BOOT)
relocates[1] the XEN image
On 30/08/18 08:33, Jan Beulich wrote:
On 29.08.18 at 19:15, wrote:
>> On 26/07/18 14:07, Jan Beulich wrote:
>>> Don't chance having Spectre v1 (including BCBS) gadgets. In some of the
>>> cases the insertions are more of precautionary nature rather than there
>>> provably being a gadget, but
On 30/08/18 07:21, Jan Beulich wrote:
>> +
>> + If unsure, say Y.
>> +
>>
>> config SHADOW_PAGING
> No double blank lines please.
>
> My previously voiced reservations wrt the shim remain. I continue
> to disagree with Andrew that the symbol needs to
flight 127001 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127001/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 126042
test-amd64-amd64-xl-qemut-win7-amd64
flight 127033 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127033/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 8846b8448acb98ba31b203ac6c2ad45be2b96ad9
baseline version:
freebsd
flight 127052 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127052/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 126996
Tests which
c/s 580c45869 "Call arch_domain_create() as early as possible in
domain_create()" overlooked the fact that ARM uses is_hardware_domain() in at
least two places during arch_domain_create().
The bug manifests as:
(XEN) Freed 292kB init memory.
(XEN) traps.c:2017:d0v0 HSR=0x938c0007
On 08/31/2018 06:14 PM, Julien Grall wrote:
Hi,
> On 08/31/2018 06:01 PM, Amit Singh Tomar wrote:
>> While porting XEN on Amlogic SoC we found that in absence of
>> image_size field of XEN image header, bootloader(U-BOOT)
>> relocates[1] the XEN image to an address(not appropriate
>> for
flight 127008 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127008/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
build-amd64-libvirt
Hi,
On 08/31/2018 06:01 PM, Amit Singh Tomar wrote:
While porting XEN on Amlogic SoC we found that in absence of
image_size field of XEN image header, bootloader(U-BOOT)
relocates[1] the XEN image to an address(not appropriate
for Amlogic) derived from text_offset.
IHMO, this is a bug in
On Thu, Aug 30, 2018 at 03:18:04PM +, Joshua Perrett wrote:
> Uses MD5 on the host mac address, vm name and vif index to generate the
> last three bytes of the vm mac address (for each vm).
>
> It uses the vif index to account for multiple vifs.
>
> MD5 code is originally from the public
While porting XEN on Amlogic SoC we found that in absence of
image_size field of XEN image header, bootloader(U-BOOT)
relocates[1] the XEN image to an address(not appropriate
for Amlogic) derived from text_offset.
This unwanted situation can be fixed by updating image_size field
along side kernel
On Fri, Aug 31, 2018 at 05:22:05PM +0200, Juergen Gross wrote:
> The topology information obtainable via XEN_SYSCTL_cputopoinfo is
> filled rather weird: the size of the array is derived from the highest
> online cpu number, so in case there are trailing offline cpus they
> will not be included.
>
Today the topology information obtained via XEN_SYSCTL_cputopoinfo
doesn't contain the thread id. Add that.
As especially with the boot parameter "smt=0" offline cpus are more
common these days add a state indicator (online/offline) to the
returned information as well.
Signed-off-by: Juergen
Add the thread-id to the cpu config data and an accessor macro
cpu_to_thread().
Signed-off-by: Juergen Gross
---
xen/arch/x86/cpu/common.c | 1 +
xen/arch/x86/smpboot.c | 10 ++
xen/include/asm-arm/processor.h | 1 +
xen/include/asm-x86/processor.h | 2 ++
The topology information printed via "xl info -n" doesn't contain the
thread id of the cpu. Additionally especially with the "smt=0" boot
option it is interesting to know which cpu is online or offline.
This patch series adds the respective information to the cpu topology
information.
This patch
flight 127047 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127047/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 126996
Tests which
>>> On 31.08.18 at 12:56, wrote:
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -55,7 +55,7 @@ endif
>
> CFLAGS += -nostdinc -fno-builtin -fno-common
> CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
> -CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
> +CFLAGS +=
>>> On 31.08.18 at 15:56, wrote:
> On Mi, 2018-08-29 at 08:13 -0600, Jan Beulich wrote:
>> > > > On 29.08.18 at 16:02, wrote:
>> > On Mi, 2018-08-22 at 18:15 +0300, Isaila Alexandru wrote:
>> > > On Mi, 2018-08-22 at 16:41 +0200, Roger Pau Monné wrote:
>> > > >
>> > > > If you look at vcpu_hvm
With not all physical cpus online (e.g. with smt=0) the output of hte
vcpu affinities is wrong, as the affinity bitmaps are capped after
nr_cpus bits, instead of using max_cpu_id.
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
tools/xl/xl_vcpu.c | 4 ++--
1 file changed, 2 insertions(+), 2
With smt=0 some output of xl is wrong. Fix it.
Juergen Gross (2):
tools/libxl: correct vcpu affinity output with sparse physical cpu map
xen: fill topology info for online cpus only
Changes in V2:
- patch 2: print info for offline cpus, too (Jan Beulich)
Juergen Gross (2):
tools/libxl:
The topology information obtainable via XEN_SYSCTL_cputopoinfo is
filled rather weird: the size of the array is derived from the highest
online cpu number, so in case there are trailing offline cpus they
will not be included.
On a dual core system with 4 threads booted with smt=0 without this
>>> On 31.08.18 at 15:48, wrote:
> On 31/08/18 09:39, Jan Beulich wrote:
> On 30.08.18 at 17:31, wrote:
>>> @@ -2686,17 +2678,22 @@ static void *hvm_map_entry(unsigned long va, bool_t
>>> *writable)
>>> pfec = PFEC_page_present;
>>> gfn = paging_gva_to_gfn(current, va, );
>>>
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.19b-rc2-tag
xen: fixes for 4.19-rc2
It contains:
- minor cleanup avoiding a warning when building with new gcc
- a patch to add a new sysfs node for Xen frontend/backend drivers
On 31/08/18 08:24, Jan Beulich wrote:
On 30.08.18 at 20:37, wrote:
>> Refreshing XenServer's patchqueue has shown that I missed this adjustment in
>> the upstream backports of the final version of the XSA-273 fixes.
>>
>> The code does work in 4.7 and earlier, but only because the eventual
On Mi, 2018-08-29 at 08:13 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 29.08.18 at 16:02, wrote:
> > On Mi, 2018-08-22 at 18:15 +0300, Isaila Alexandru wrote:
> > >
> > > On Mi, 2018-08-22 at 16:41 +0200, Roger Pau Monné wrote:
> > > >
> > > > If you look at vcpu_hvm in
flight 127042 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127042/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 126996
Tests which
On 31/08/18 09:39, Jan Beulich wrote:
On 30.08.18 at 17:31, wrote:
>> --- a/xen/arch/arm/mem_access.c
>> +++ b/xen/arch/arm/mem_access.c
>> @@ -293,12 +293,7 @@ bool p2m_mem_access_check(paddr_t gpa, vaddr_t gla,
>> const struct npfec npfec)
>> {
>> /* No listener */
>>
On 30.08.2018 21:35, Pasha Tatashin wrote:
>> +
>> +void __ref remove_memory(int nid, u64 start, u64 size)
>
> Remove __ref, otherwise looks good:
Indeed, will do.
Thanks for the review. Will resend in two weeks when I'm back from vacation.
Cheers!
>
> Reviewed-by: Pavel Tatashin
>
>> +{
On Thu, Aug 30, 2018 at 6:00 PM Boris Ostrovsky
wrote:
>
> On 08/29/2018 08:51 PM, Andy Smith wrote:
> > Hi,
> >
> > I'm sorry this is a long email, but I wanted to explain everything
> > that I have tried, because it seems like quite a few different
> > versions of 32-bit upstream Linux kernel
flight 127016 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127016/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a77e5bcac54d2e2437d7deaec9af5362c9220037
baseline version:
ovmf
flight 75147 distros-debian-jessie real [real]
http://osstest.xensource.com/osstest/logs/75147/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-jessie-netboot-pygrub 10 debian-di-install fail REGR.
vs. 75115
Tests
On 31/08/18 12:57, Julien Grall wrote:
> (+ Juergen)
>
> On 08/31/2018 11:42 AM, Jan Beulich wrote:
> On 31.08.18 at 12:33, wrote:
>>> On Wed, Aug 29, 2018 at 09:03:36AM -0600, Jan Beulich wrote:
>>> On 29.08.18 at 16:40, wrote:
> For ARM, the call to arch_domain_create() needs to
On 31/08/18 11:42, Jan Beulich wrote:
On 31.08.18 at 12:33, wrote:
>> On Wed, Aug 29, 2018 at 09:03:36AM -0600, Jan Beulich wrote:
>> On 29.08.18 at 16:40, wrote:
For ARM, the call to arch_domain_create() needs to have completed before
domain_max_vcpus() will return the
(+ Juergen)
On 08/31/2018 11:42 AM, Jan Beulich wrote:
On 31.08.18 at 12:33, wrote:
On Wed, Aug 29, 2018 at 09:03:36AM -0600, Jan Beulich wrote:
On 29.08.18 at 16:40, wrote:
For ARM, the call to arch_domain_create() needs to have completed before
domain_max_vcpus() will return the correct
Creating debug info during build is not strictly required at runtime.
Make it optional by introducing a new Kconfig knob "DEBUG_INFO".
This slightly reduces build time and diskusage, if disabled.
Signed-off-by: Olaf Hering
---
xen/Kconfig.debug | 7 +++
xen/Rules.mk | 3 ++-
2 files
flight 126978 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126978/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumprun-amd64 12 guest-startfail REGR. vs. 125898
>>> On 31.08.18 at 12:33, wrote:
> On Wed, Aug 29, 2018 at 09:03:36AM -0600, Jan Beulich wrote:
>> >>> On 29.08.18 at 16:40, wrote:
>> > For ARM, the call to arch_domain_create() needs to have completed before
>> > domain_max_vcpus() will return the correct upper bound.
>> >
>> > For each
>>> On 31.08.18 at 11:50, wrote:
> On 08/31/2018 10:25 AM, Jan Beulich wrote:
> On 31.08.18 at 11:02, wrote:
>>> On Fri, Aug 31, Jan Beulich wrote:
>>>
Perhaps better move your addition into this conditional section?
>>>
>>> Then -g would disappear when DEBUG is disabled. Is that
On 31/08/18 11:38, Jan Beulich wrote:
> Logging disabled LAPIC / x2APIC entries with invalid local APIC IDs
> (ones having "broadcast" meaning when used) isn't very useful, and can
> be quite noisy on larger systems. Suppress their logging unless
> opt_cpu_info is true.
>
> Signed-off-by: Jan
Logging disabled LAPIC / x2APIC entries with invalid local APIC IDs
(ones having "broadcast" meaning when used) isn't very useful, and can
be quite noisy on larger systems. Suppress their logging unless
opt_cpu_info is true.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/acpi/boot.c
+++
On Wed, Aug 29, 2018 at 09:03:36AM -0600, Jan Beulich wrote:
> >>> On 29.08.18 at 16:40, wrote:
> > For ARM, the call to arch_domain_create() needs to have completed before
> > domain_max_vcpus() will return the correct upper bound.
> >
> > For each arch's dom0's, drop the temporary max_vcpus
Hi Jan,
On 08/31/2018 10:25 AM, Jan Beulich wrote:
On 31.08.18 at 11:02, wrote:
On Fri, Aug 31, Jan Beulich wrote:
Perhaps better move your addition into this conditional section?
Then -g would disappear when DEBUG is disabled. Is that intentional?
It would still be available when
>>> On 31.08.18 at 11:02, wrote:
> On Fri, Aug 31, Jan Beulich wrote:
>
>> Perhaps better move your addition into this conditional section?
>
> Then -g would disappear when DEBUG is disabled. Is that intentional?
It would still be available when EXPERT=y.
Jan
On Fri, Aug 31, Jan Beulich wrote:
> Perhaps better move your addition into this conditional section?
Then -g would disappear when DEBUG is disabled. Is that intentional?
Olaf
signature.asc
Description: PGP signature
___
Xen-devel mailing list
On Fri, Aug 31, 2018 at 09:51:50AM +0100, Andrew Cooper wrote:
> On 31/08/18 09:41, Jan Beulich wrote:
> On 31.08.18 at 10:32, wrote:
> >> On Fri, Aug 31, 2018 at 10:29:21AM +0200, Olaf Hering wrote:
> >>> Creating debug info during build is not strictly required at runtime.
> >>> Make it
On 31/08/18 09:41, Jan Beulich wrote:
On 31.08.18 at 10:32, wrote:
>> On Fri, Aug 31, 2018 at 10:29:21AM +0200, Olaf Hering wrote:
>>> Creating debug info during build is not strictly required at runtime.
>>> Make it optional by introducing a new Kconfig knob "DEBUG_INFO".
>>> This slightly
>>> On 31.08.18 at 09:30, wrote:
> On 31/08/18 09:21, Jan Beulich wrote:
> On 31.08.18 at 09:12, wrote:
>>> On 31/08/18 09:04, Jan Beulich wrote:
>>> On 31.08.18 at 08:43, wrote:
> On 31/08/18 08:33, Jan Beulich wrote:
> On 30.08.18 at 19:08, wrote:
>>> On 30/08/18
>>> On 31.08.18 at 10:29, wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -11,6 +11,13 @@ config DEBUG
>
> You probably want to say 'N' here.
>
> +config DEBUG_INFO
> + bool "Compile Xen with debug info"
> + default y
> + ---help---
> + If you say Y
>>> On 31.08.18 at 10:32, wrote:
> On Fri, Aug 31, 2018 at 10:29:21AM +0200, Olaf Hering wrote:
>> Creating debug info during build is not strictly required at runtime.
>> Make it optional by introducing a new Kconfig knob "DEBUG_INFO".
>> This slightly reduces build time and diskusage, if
On Fri, Aug 31, Wei Liu wrote:
> But what is the difference between this and DEBUG anyway?
DEBUG_INFO is for gcc (-g), DEBUG is for Kconfig.
Adding a dependency to DEBUG may change behavior, not sure what the
expected outcome of always using '-g' is.
Olaf
signature.asc
Description: PGP
>>> On 30.08.18 at 17:31, wrote:
> --- a/xen/arch/arm/mem_access.c
> +++ b/xen/arch/arm/mem_access.c
> @@ -293,12 +293,7 @@ bool p2m_mem_access_check(paddr_t gpa, vaddr_t gla,
> const struct npfec npfec)
> {
> /* No listener */
> if ( p2m->access_required )
> -{
>
On Fri, Aug 31, 2018 at 10:29:21AM +0200, Olaf Hering wrote:
> Creating debug info during build is not strictly required at runtime.
> Make it optional by introducing a new Kconfig knob "DEBUG_INFO".
> This slightly reduces build time and diskusage, if disabled.
>
> Signed-off-by: Olaf Hering
>
Creating debug info during build is not strictly required at runtime.
Make it optional by introducing a new Kconfig knob "DEBUG_INFO".
This slightly reduces build time and diskusage, if disabled.
Signed-off-by: Olaf Hering
---
xen/Kconfig.debug | 7 +++
xen/Rules.mk | 5 -
2 files
On 31/08/18 09:21, Jan Beulich wrote:
On 31.08.18 at 09:12, wrote:
>> On 31/08/18 09:04, Jan Beulich wrote:
>> On 31.08.18 at 08:43, wrote:
On 31/08/18 08:33, Jan Beulich wrote:
On 30.08.18 at 19:08, wrote:
>> On 30/08/18 15:07, Jan Beulich wrote:
>> On
>>> On 30.08.18 at 20:37, wrote:
> Refreshing XenServer's patchqueue has shown that I missed this adjustment in
> the upstream backports of the final version of the XSA-273 fixes.
>
> The code does work in 4.7 and earlier, but only because the eventual value of
> (opt_pv_l1tf & OPT_PV_L1TF_DOMx)
>>> On 31.08.18 at 09:12, wrote:
> On 31/08/18 09:04, Jan Beulich wrote:
> On 31.08.18 at 08:43, wrote:
>>> On 31/08/18 08:33, Jan Beulich wrote:
>>> On 30.08.18 at 19:08, wrote:
> On 30/08/18 15:07, Jan Beulich wrote:
> On 30.08.18 at 14:31, wrote:
>>> The observant
flight 126977 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126977/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail in
126810 pass in 126977
On 31/08/18 09:04, Jan Beulich wrote:
On 31.08.18 at 08:43, wrote:
>> On 31/08/18 08:33, Jan Beulich wrote:
>> On 30.08.18 at 19:08, wrote:
On 30/08/18 15:07, Jan Beulich wrote:
On 30.08.18 at 14:31, wrote:
>> The observant amongst you might realise that this reverts
>>> On 31.08.18 at 08:43, wrote:
> On 31/08/18 08:33, Jan Beulich wrote:
> On 30.08.18 at 19:08, wrote:
>>> On 30/08/18 15:07, Jan Beulich wrote:
>>> On 30.08.18 at 14:31, wrote:
> The observant amongst you might realise that this reverts parts of c/s
> 51ad90aea21c - What can I
Assuming it was intentional for this test utility, other than most other
ones, to always be built, I think it would be nice if it didn't fail to
build on really old distros just because of the lack of a TUNGETIFF
definition.
Signed-off-by: Jan Beulich
---
On 31/08/18 08:33, Jan Beulich wrote:
On 30.08.18 at 19:08, wrote:
>> On 30/08/18 15:07, Jan Beulich wrote:
>> On 30.08.18 at 14:31, wrote:
The observant amongst you might realise that this reverts parts of c/s
51ad90aea21c - What can I say? Several years of hindsight is very
>>> On 30.08.18 at 19:08, wrote:
> On 30/08/18 15:07, Jan Beulich wrote:
> On 30.08.18 at 14:31, wrote:
>>> The observant amongst you might realise that this reverts parts of c/s
>>> 51ad90aea21c - What can I say? Several years of hindsight is very useful,
>>> and
>>> at the time I did ask
>>> On 30.08.18 at 20:09, wrote:
> On Thu, Aug 30, 2018 at 09:49:58AM -0600, Jan Beulich wrote:
>> >>> On 27.08.18 at 18:55, wrote:
>> > --- a/xen/arch/x86/spec_ctrl.c
>> > +++ b/xen/arch/x86/spec_ctrl.c
>> > @@ -20,6 +20,7 @@
>> > #include
>> > #include
>> > #include
>> > +#include
>> >
76 matches
Mail list logo
