Xen's vGIC implementation supports a maximum number of 992 IRQ lines.
GICv2 specification allows for 1020 IRQ lines.
This commit adds a check for this discrepancy.
Signed-off-by: Lukas Juenger (juen...@ice.rwth-aachen.de)
---
xen/arch/arm/setup.c | 8 +++-
1 file changed, 7 insertions(+), 1 d
>>> On 26.03.19 at 18:21, wrote:
> zeta /usr/local/src/xen # cat xen/.config |grep CONFIG_HVM
> # CONFIG_HVM is not set
> zeta /usr/local/src/xen #
>
> # tried 2 boot attempts
> log at: https://pastebin.com/nL4BWJ6Y
>
> Hang points at lines:
Thanks for trying anyway; one further possibility el
On 2019/3/26 23:49, Jan Beulich wrote:
> On 25.03.19 at 14:29, wrote:
>> -static unsigned int __initdata opt_cpuid_mask_l7s0_eax = ~0u;
>> -integer_param("cpuid_mask_l7s0_eax", opt_cpuid_mask_l7s0_eax);
>> -static unsigned int __initdata opt_cpuid_mask_l7s0_ebx = ~0u;
>> -integer_param("cpuid_mask
On 2019/3/27 0:10, Jan Beulich wrote:
> On 25.03.19 at 14:30, wrote:
>> --- a/xen/arch/x86/cpu/vpmu_amd.c
>> +++ b/xen/arch/x86/cpu/vpmu_amd.c
>> @@ -538,13 +538,37 @@ int svm_vpmu_initialise(struct vcpu *v)
>> return 0;
>> }
>>
>> -int __init amd_vpmu_init(void)
>> +static int _vpmu_in
>>> On 27.03.19 at 09:14, wrote:
> On 2019/3/26 23:49, Jan Beulich wrote:
>> On 25.03.19 at 14:29, wrote:
>>> @@ -116,6 +121,9 @@ bool __init probe_cpuid_faulting(void)
>>> uint64_t val;
>>> int rc;
>>>
>>> + if(boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
>>> + return fal
>>> On 27.03.19 at 09:16, wrote:
> On 2019/3/27 0:10, Jan Beulich wrote:
>> On 25.03.19 at 14:30, wrote:
>>> -for ( i = 0; i < num_counters; i++ )
>>> +int __init hygon_vpmu_init(void)
>>> +{
>>> +switch ( current_cpu_data.x86 )
>>> {
>>> -rdmsrl(ctrls[i], ctrl_rsvd[i]);
>>>
flight 134090 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134090/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
On Tue, Mar 26, 2019 at 07:21:31PM -0400, Boris Ostrovsky wrote:
> On 3/26/19 5:13 AM, Dario Faggioli wrote:
> > On Mon, 2019-03-25 at 09:43 -0400, Boris Ostrovsky wrote:
> >> On 3/25/19 8:05 AM, luca abeni wrote:
> >>> The picture shows the latencies measured with an unpatched guest
> >>> kernel
>
On 2019/3/27 16:31, Jan Beulich wrote:
> On 27.03.19 at 09:14, wrote:
>> On 2019/3/26 23:49, Jan Beulich wrote:
>>> On 25.03.19 at 14:29, wrote:
@@ -116,6 +121,9 @@ bool __init probe_cpuid_faulting(void)
uint64_t val;
int rc;
+ if(boot_cpu_data.
On 2019/3/27 16:38, Jan Beulich wrote:
On 27.03.19 at 09:16, wrote:
On 2019/3/27 0:10, Jan Beulich wrote:
On 25.03.19 at 14:30, wrote:
+default:
+printk(XENLOG_WARNING "VPMU: Unsupported CPU family %#x\n",
+ current_cpu_data.x86);
+return -EINVAL;
}
flight 134122 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134122/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
coverity-amd647 coverity-upload fail REGR. vs. 133615
version t
Hi Jan,
Thanks for reviewing.
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, March 26, 2019 9:15 PM
> To: Xin Li
> Cc: Andrew Cooper ; Igor Druzhinin
> ; Sergey Dyasli ; Xin Li
> (Talons) ; xen-de...@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH
flight 134107 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134107/
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 3/25/19 3:24 PM, Jan Beulich wrote:
On 21.03.19 at 21:26, wrote:
>> It turns out that this code was previously dead.
>
> If it was entirely dead, why the rush to get the change into 4.12?
> (I suppose the later parts of description are then justifying why
> the code wasn't actually dead,
>>> On 27.03.19 at 11:54, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, March 26, 2019 9:15 PM
>>
>> >>> On 26.03.19 at 07:45, wrote:
>> > @@ -518,7 +520,67 @@ smbios_type_2_init(void *start)
>> > return (start + length);
>> > }
>>
>> In the subject you
flight 83830 distros-debian-squeeze real [real]
http://osstest.xensource.com/osstest/logs/83830/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
>>> On 27.03.19 at 12:02, wrote:
> On 3/25/19 3:24 PM, Jan Beulich wrote:
> On 21.03.19 at 21:26, wrote:
>>> It turns out that this code was previously dead.
>>
>> If it was entirely dead, why the rush to get the change into 4.12?
>> (I suppose the later parts of description are then justify
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, March 27, 2019 7:24 PM
> To: Xin Li (Talons)
> Cc: Andrew Cooper ; Igor Druzhinin
> ; Sergey Dyasli ; Xin Li
> ; xen-de...@lists.xen.org
> Subject: RE: [Xen-devel] [PATCH v1 1/1] hvmloader: allow overr
On 3/18/19 1:11 PM, Juergen Gross wrote:
> Add a helper cpu_notifier_call_chain() to call notifier_call_chain()
> for a cpu with a specified action, returning an errno value.
>
> This avoids coding the same pattern multiple times.
>
> Signed-off-by: Juergen Gross
Reviewed-by: George Dunlap
__
On 3/27/2019 1:14 AM, Jan Beulich wrote:
On 26.03.19 at 18:21, wrote:
zeta /usr/local/src/xen # cat xen/.config |grep CONFIG_HVM
# CONFIG_HVM is not set
zeta /usr/local/src/xen #
# tried 2 boot attempts
log at: https://pastebin.com/nL4BWJ6Y
Hang points at lines:
Thanks for trying anyway; on
Hi,
Currently, when specifying a virtual disk, the only way to determine the
emulation model used is by selecting a particular 'vdev' numbering scheme as
detailed in xl-disk-configuration in the docs. That document refers the reader
to xen-vbd-interface which says:
xvd* -> xen virtual disk (
>>> On 27.03.19 at 14:25, wrote:
> On 3/27/2019 1:14 AM, Jan Beulich wrote:
> On 26.03.19 at 18:21, wrote:
>>> zeta /usr/local/src/xen # cat xen/.config |grep CONFIG_HVM
>>> # CONFIG_HVM is not set
>>> zeta /usr/local/src/xen #
>>>
>>> # tried 2 boot attempts
>>> log at: https://pastebin.com/
> -Original Message-
> From: Paul Durrant
> Sent: 27 March 2019 13:54
> To: xen-devel (xen-devel@lists.xenproject.org)
>
> Subject: xen disk spec and emulation
>
> Hi,
>
> Currently, when specifying a virtual disk, the only way to determine the
> emulation model used is by
> selectin
>>> On 27.03.19 at 14:54, wrote:
> Currently, when specifying a virtual disk, the only way to determine the
> emulation model used is by selecting a particular 'vdev' numbering scheme as
> detailed in xl-disk-configuration in the docs. That document refers the
> reader to xen-vbd-interface wh
On 3/27/19 6:00 AM, Ryan Thibodeaux wrote:
> On Tue, Mar 26, 2019 at 07:21:31PM -0400, Boris Ostrovsky wrote:
>> On 3/26/19 5:13 AM, Dario Faggioli wrote:
>>> On Mon, 2019-03-25 at 09:43 -0400, Boris Ostrovsky wrote:
On 3/25/19 8:05 AM, luca abeni wrote:
> The picture shows the latencies m
>>> On 26.03.19 at 22:56, wrote:
> On 3/26/19 10:54 AM, Jan Beulich wrote:
> On 19.03.19 at 17:12, wrote:
>>> On 3/15/19 3:37 AM, Jan Beulich wrote:
Furthermore I'm then once again wondering what the gain is
over using the ACPI driver: The suggested _CST looks to exactly
match
On 3/25/19 10:40 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
>> Jennifer Herbert
>> Sent: 25 March 2019 14:24
>> To: Boris Ostrovsky ; x...@kernel.org;
>> xen-devel@lists.xenproject.org;
>> linux-ker...@vger
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 27 March 2019 14:27
> To: Paul Durrant
> Cc: xen-devel
> Subject: Re: [Xen-devel] xen disk spec and emulation
>
> >>> On 27.03.19 at 14:54, wrote:
> > Currently, when specifying a virtual disk, the only way to
On 26/03/2019 13:39, Jan Beulich wrote:
On 26.03.19 at 13:43, wrote:
>> On 26/03/2019 09:08, Jan Beulich wrote:
>> Leave the warning which identifies the problematic devices, but drop the
>> remaining logic. This leaves the system in better overall state, and
>> working
>> i
On Wed, Mar 27, 2019 at 10:46:21AM -0400, Boris Ostrovsky wrote:
> On 3/27/19 6:00 AM, Ryan Thibodeaux wrote:
> > On Tue, Mar 26, 2019 at 07:21:31PM -0400, Boris Ostrovsky wrote:
> >> On 3/26/19 5:13 AM, Dario Faggioli wrote:
> >>> On Mon, 2019-03-25 at 09:43 -0400, Boris Ostrovsky wrote:
> On
This started out with me noticing that "dom0_max_vcpus=" with
larger than the number of physical CPUs reported through ACPI tables
would not bring up the "excess" vCPU-s.
Noticing that xen_fill_possible_map() gets called way too early, whereas
xen_filter_cpu_maps() gets called too late (after per
On Wed, 2019-03-27 at 10:46 -0400, Boris Ostrovsky wrote:
> On 3/27/19 6:00 AM, Ryan Thibodeaux wrote:
> > On Tue, Mar 26, 2019 at 07:21:31PM -0400, Boris Ostrovsky wrote:
> > > On 3/26/19 5:13 AM, Dario Faggioli wrote:
> > > >
> > > > And this is basically why I was also thinking we can/should
>
In the case of any errors, finish_type_change() passes values returned
from p2m->recalc() up the stack (with some exceptions in the case where
an error is expected); this eventually ends up being returned to the
XEN_DOMOP_map_mem_type_to_ioreq_server hypercall.
However, on Intel processors (but no
On 26/03/2019 14:39, Jan Beulich wrote:
On 26.03.19 at 15:23, wrote:
>> IMO especially in the CPUID case it is desirable to explicitly specify
>> the width of the data. Looking at nodes 0x8002 and following this
>> should be rather clear (and I even think get_model_name() should be
>> mod
On 3/18/19 1:11 PM, Juergen Gross wrote:
> cpu_disable_scheduler() is being called from __cpu_disable() today.
> There is no need to call it on the cpu just being disabled, so use
> the CPU_DEAD case of the cpu notifier chain.
>
> Signed-off-by: Juergen Gross
Scheduler change:
Acked-by: George
>>> On 27.03.19 at 15:38, wrote:
> There is absolutely nothing *at all* which guarantees that just because
> a number of devices are identified to be behind specific IOMMUs, that
> DMA wont start appearing from elsewhere in the system.
I fully agree here.
> Security of the system when it comes t
On 3/17/19 4:01 AM, Ming Lei wrote:
> Hi,
>
> Now the whole IO stack is capable of handling multi-page bvec, and it has
> been enabled in the normal FS IO path. However, it isn't done for
> passthrough IO.
>
> Without enabling multi-bvec for passthough IO, we won't go ahead for
> optimizing relat
On 3/18/19 1:11 PM, Juergen Gross wrote:
> Add a new cpu notifier action CPU_RESUME_FAILED which is called for all
> cpus which failed to come up at resume. The calls will be done after
> all other cpus are already up.
>
> Signed-off-by: Juergen Gross
Reviewed-by: George Dunlap
___
On 18/03/2019 13:11, Juergen Gross wrote:
> cpu_disable_scheduler() is being called from __cpu_disable() today.
> There is no need to call it on the cpu just being disabled, so use
> the CPU_DEAD case of the cpu notifier chain.
>
> Signed-off-by: Juergen Gross
> ---
> xen/arch/x86/smpboot.c | 3
On Mon, 2019-03-25 at 13:29 +0100, Juergen Gross wrote:
> On 25/03/2019 13:21, Dario Faggioli wrote:
>
> > Reviewed-by: Dario Faggioli
> >
> > One more (minor) thing...
> >
> > > /* CPU_REMOVE: CPU was removed. */
> > > -#define CPU_REMOVE (0x0009 | NOTIFY_REVERSE)
> > > +#define CPU_REMO
On 3/18/19 1:11 PM, Juergen Gross wrote:
> Instead of removing cpus temporarily from cpupools during
> suspend/resume only remove cpus finally which didn't come up when
> resuming.
>
> Signed-off-by: Juergen Gross
Looks good overall -- one comment...
> @@ -774,10 +741,15 @@ static int cpu_callb
On 18/03/2019 13:11, Juergen Gross wrote:
> Add a helper cpu_notifier_call_chain() to call notifier_call_chain()
> for a cpu with a specified action, returning an errno value.
>
> This avoids coding the same pattern multiple times.
>
> Signed-off-by: Juergen Gross
> ---
> xen/common/cpu.c | 50 ++
On 20.12.18 14:08, Michal Hocko wrote:
> On Thu 20-12-18 13:58:16, David Hildenbrand wrote:
>> On 30.11.18 18:59, David Hildenbrand wrote:
>>> This is the second approach, introducing more meaningful memory block
>>> types and not changing online behavior in the kernel. It is based on
>>> latest li
On 27/03/2019 16:39, Andrew Cooper wrote:
> On 18/03/2019 13:11, Juergen Gross wrote:
>> Add a helper cpu_notifier_call_chain() to call notifier_call_chain()
>> for a cpu with a specified action, returning an errno value.
>>
>> This avoids coding the same pattern multiple times.
>>
>> Signed-off-by
flight 134102 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134102/
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 27.03.19 at 16:21, wrote:
> @@ -621,7 +623,7 @@ bool_t ept_handle_misconfig(uint64_t gpa)
>
> p2m_unlock(p2m);
>
> -return spurious ? (rc >= 0) : (rc > 0);
> +return spurious && !rc;
> }
I think you've gone too far now: This is - afaict - the one place
where the distincti
On 18/03/2019 13:11, Juergen Gross wrote:
> Instead of freeing percpu areas during suspend and allocating them
> again when resuming keep them. Only free an area in case a cpu didn't
> come up again when resuming.
>
> Signed-off-by: Juergen Gross
Hmm - this is slightly problematic, given the dual
On 27/03/2019 16:55, Andrew Cooper wrote:
> On 18/03/2019 13:11, Juergen Gross wrote:
>> Instead of freeing percpu areas during suspend and allocating them
>> again when resuming keep them. Only free an area in case a cpu didn't
>> come up again when resuming.
>>
>> Signed-off-by: Juergen Gross
>
>>> On 18.03.19 at 14:11, wrote:
> @@ -1738,6 +1733,9 @@ static int cpu_schedule_callback(
> rc = cpu_schedule_up(cpu);
> break;
> case CPU_DEAD:
> +rcu_read_lock(&domlist_read_lock);
> +cpu_disable_scheduler(cpu);
> +rcu_read_unlock(&domlist_read_loc
On Mon, 2019-03-18 at 14:11 +0100, Juergen Gross wrote:
> cpu_disable_scheduler() is being called from __cpu_disable() today.
> There is no need to call it on the cpu just being disabled, so use
> the CPU_DEAD case of the cpu notifier chain.
>
So, what do you mean with "There is no need to call it
>>> On 18.03.19 at 14:11, wrote:
> --- a/xen/common/cpu.c
> +++ b/xen/common/cpu.c
> @@ -214,7 +214,12 @@ void enable_nonboot_cpus(void)
> printk("Error bringing CPU%d up: %d\n", cpu, error);
> BUG_ON(error == -EBUSY);
> }
> +else
> +__cpumask
On 27/03/2019 17:24, Dario Faggioli wrote:
> On Mon, 2019-03-18 at 14:11 +0100, Juergen Gross wrote:
>> cpu_disable_scheduler() is being called from __cpu_disable() today.
>> There is no need to call it on the cpu just being disabled, so use
>> the CPU_DEAD case of the cpu notifier chain.
>>
> So,
On 27/03/2019 17:29, Jan Beulich wrote:
On 18.03.19 at 14:11, wrote:
>> --- a/xen/common/cpu.c
>> +++ b/xen/common/cpu.c
>> @@ -214,7 +214,12 @@ void enable_nonboot_cpus(void)
>> printk("Error bringing CPU%d up: %d\n", cpu, error);
>> BUG_ON(error == -EBUSY);
>>
On Mon, 2019-03-18 at 14:11 +0100, Juergen Gross wrote:
> Instead of removing cpus temporarily from cpupools during
> suspend/resume only remove cpus finally which didn't come up when
> resuming.
>
> Signed-off-by: Juergen Gross
> ---
> xen/common/cpupool.c | 130 ++
>>> On 27.03.19 at 17:18, wrote:
> On 27/03/2019 16:55, Andrew Cooper wrote:
>> On 18/03/2019 13:11, Juergen Gross wrote:
>>> Instead of freeing percpu areas during suspend and allocating them
>>> again when resuming keep them. Only free an area in case a cpu didn't
>>> come up again when resuming
On 3/27/19 3:21 PM, Alexandru Stefan ISAILA wrote:
> In the case of any errors, finish_type_change() passes values returned
> from p2m->recalc() up the stack (with some exceptions in the case where
> an error is expected); this eventually ends up being returned to the
> XEN_DOMOP_map_mem_type_to_io
On 27/03/2019 17:22, Jan Beulich wrote:
On 18.03.19 at 14:11, wrote:
>> @@ -1738,6 +1733,9 @@ static int cpu_schedule_callback(
>> rc = cpu_schedule_up(cpu);
>> break;
>> case CPU_DEAD:
>> +rcu_read_lock(&domlist_read_lock);
>> +cpu_disable_scheduler(cpu
On 27/03/2019 17:38, Jan Beulich wrote:
On 27.03.19 at 17:18, wrote:
>> On 27/03/2019 16:55, Andrew Cooper wrote:
>>> On 18/03/2019 13:11, Juergen Gross wrote:
Instead of freeing percpu areas during suspend and allocating them
again when resuming keep them. Only free an area in case
On Wed, 2019-03-27 at 17:31 +0100, Juergen Gross wrote:
> On 27/03/2019 17:24, Dario Faggioli wrote:
> > On Mon, 2019-03-18 at 14:11 +0100, Juergen Gross wrote:
> > > cpu_disable_scheduler() is being called from __cpu_disable()
> > > today.
> > > There is no need to call it on the cpu just being di
On 27/03/2019 17:51, Dario Faggioli wrote:
> On Wed, 2019-03-27 at 17:31 +0100, Juergen Gross wrote:
>> On 27/03/2019 17:24, Dario Faggioli wrote:
>>> On Mon, 2019-03-18 at 14:11 +0100, Juergen Gross wrote:
cpu_disable_scheduler() is being called from __cpu_disable()
today.
There is
>>> On 27.03.19 at 17:45, wrote:
> On 27/03/2019 17:22, Jan Beulich wrote:
>> Also while indeed (as the description says) there's no need to
>> run the function on the CPU itself, it's not obvious to me that
>> it's safe to run it outside of stop_machine() context. Or to be
>> more precise, it's n
On 3/27/19 11:12 AM, Jan Beulich wrote:
> -
> -static void __init xen_filter_cpu_maps(void)
> +static void __init _get_smp_config(unsigned int early)
> {
> int i, rc;
> unsigned int subtract = 0;
>
> - if (!xen_initial_domain())
> + if (early)
> return;
>
>
On 27/03/2019 17:58, Jan Beulich wrote:
On 27.03.19 at 17:45, wrote:
>> On 27/03/2019 17:22, Jan Beulich wrote:
>>> Also while indeed (as the description says) there's no need to
>>> run the function on the CPU itself, it's not obvious to me that
>>> it's safe to run it outside of stop_machin
flight 134127 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134127/
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 3/27/19 9:48 AM, Jan Beulich wrote:
On 26.03.19 at 22:56, wrote:
>> On 3/26/19 10:54 AM, Jan Beulich wrote:
>> On 19.03.19 at 17:12, wrote:
On 3/15/19 3:37 AM, Jan Beulich wrote:
> Furthermore I'm then once again wondering what the gain is
> over using the ACPI driver: Th
The Xen blkif protocol requires that sector based quantities should be
interpreted strictly as multiples of 512 bytes. Specifically:
"first_sect and last_sect in blkif_request_segment, as well as
sector_number in blkif_request, are always expressed in 512-byte units."
This patch modifies the xen-
The Xen blkif protocol is confusing but discussion with the maintainer
has clarified that sector based quantities in requests and the 'sectors'
value advertized in xenstore should always be in terms of 512-byte
units and not the advertised logical 'sector-size' value.
This series fixes xen-block t
The mail thread at [1] clarifies that the Xen blkif protocol requires that
'sectors' value reported in xenstore is strictly in terms of 512-byte
units and is not dependent on the logical sector size reported in
'sector-size'.
[1] https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg0160
On 27/03/2019 17:32, Paul Durrant wrote:
> The Xen blkif protocol is confusing but discussion with the maintainer
> has clarified that sector based quantities in requests and the 'sectors'
> value advertized in xenstore should always be in terms of 512-byte
> units and not the advertised logical 's
Clang 8.0 throws an error in the get_top_bit function:
guest_walk.c:328:15: error: variable 'topbit' is used uninitialized
whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
else if ( is_64bit_domain(d) )
^~
This is happening because clang think
Clang is pickier than GCC for the register size in asm statement. It
expects the register size to match the value size.
The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
(resp. Arm64) whereas the value is a boolean (Clang consider to be
32-bit).
It would be possible to impose 32-bi
Clang uses "-target" option for cross-compilation.
Signed-off-by: Julien Grall
---
config/StdGNU.mk | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 039274ea61..48c50b5ad7 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@
Clang understands the GCCism in use here, but still complains that sp is
unitialised. In such cases, resort to the older versions of this code,
which directly read sp into the temporary variable.
Note that we still keep the GCCism in the default case, as it causes GCC
to create rather better assem
Clang is pickier than GCC for the register size in asm statement. It
expects the register size to match the value size.
The instructions msr/mrs are expecting a 64-bit register. This means the
implementation of the 32-bit helpers is not correct. The easiest
solution is to implement the 32-bit help
Clang is pickier than GCC for the register size in asm statement. It expects
the register size to match the value size.
The instruction clz is expecting the two operands to be the same size
(i.e 32-bit or 64-bit). As the flsl function is dealing with 64-bit
value, we need to make the destination v
The commit 8d84e701fd "xen/arm: initialize access" initializes
*access using the wrong enumeration type. This result to a warning
using clang:
mem_access.c:50:20: error: implicit conversion from enumeration type
'p2m_access_t' to different enumeration type 'xenmem_access_t'
[-Werror,-Wenum-convers
Clang is pickier than GCC for the register size in asm statement. It
expects the register size to match the value size.
The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
(resp. Arm64) whereas the value is a boolean (Clang consider to be
32-bit).
It would be possible to impose 32-bi
Clang will throw an error if a function is unused unless you tell
to ignore it. This can be done using __maybe_unused.
Signed-off-by: Julien Grall
---
xen/arch/arm/traps.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index d8b9
Currently __cmpxchg_mb and __cmpxchg are only marked inline. The
compiler is free to decide to not honor the inline. This will result to
generate code use __bad_cmpxchg and lead a link failure.
This was caught by Clang 8.0.
Signed-off-by: Julien Grall
---
xen/include/asm-arm/arm64/cmpxchg.h | 1
The header guard for xilinx-zynqmp-eemi.h is not followed by a #define
of the macro used in the guard.
Signed-off-by: Julien Grall
---
xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/platforms/xilinx-zynqm
Hi all,
This series adds support to build Xen Arm with clang. This series was tested
with clang 8.0.
Note that I only did build for arm64. I still need to look at the arm32
build.
Cheers,
Julien Grall (12):
xen: clang: Support correctly cross-compile
xen/arm: fix get_cpu_info() when built w
Clang will throw an error if a function is unused unless you tell
to ignore it. This can be done using __maybe_unused.
Signed-off-by: Julien Grall
---
xen/arch/arm/mm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 01ae20..d
On 27/03/2019 18:45, Julien Grall wrote:
> Clang is pickier than GCC for the register size in asm statement. It expects
> the register size to match the value size.
>
> The instruction clz is expecting the two operands to be the same size
> (i.e 32-bit or 64-bit). As the flsl function is dealing wi
On 3/27/19 8:45 PM, Julien Grall wrote:
> The commit 8d84e701fd "xen/arm: initialize access" initializes
> *access using the wrong enumeration type. This result to a warning
> using clang:
>
> mem_access.c:50:20: error: implicit conversion from enumeration type
> 'p2m_access_t' to different enumer
On 27/03/2019 18:45, Julien Grall wrote:
> Clang will throw an error if a function is unused unless you tell
> to ignore it. This can be done using __maybe_unused.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/mm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/
On 27/03/2019 18:45, Julien Grall wrote:
> Clang is pickier than GCC for the register size in asm statement. It
> expects the register size to match the value size.
>
> The instructions msr/mrs are expecting a 64-bit register. This means the
> implementation of the 32-bit helpers is not correct. Th
This has been problematic since its introduction in Xen 4.3
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/hvm/vmx/vvmx.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x
flight 134109 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134109/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
Hi,
On 27/03/2019 19:03, Andrew Cooper wrote:
> On 27/03/2019 18:45, Julien Grall wrote:
>> Clang is pickier than GCC for the register size in asm statement. It expects
>> the register size to match the value size.
>>
>> The instruction clz is expecting the two operands to be the same size
>> (i.e
Hi,
On 27/03/2019 19:15, Andrew Cooper wrote:
> On 27/03/2019 18:45, Julien Grall wrote:
>> Clang is pickier than GCC for the register size in asm statement. It
>> expects the register size to match the value size.
>>
>> The instructions msr/mrs are expecting a 64-bit register. This means the
>> i
> -Original Message-
> From: Andrew Cooper
> Sent: 27 March 2019 18:20
> To: Paul Durrant ; xen-devel@lists.xenproject.org;
> qemu-bl...@nongnu.org;
> qemu-de...@nongnu.org
> Cc: Kevin Wolf ; Stefano Stabellini
> ; Max Reitz
> ; Stefan Hajnoczi ; Anthony Perard
>
> Subject: Re: [Xen-dev
flight 134136 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134136/
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
flight 134113 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134113/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c455bc8c8d78ad51c24426a500914ea32504bf06
baseline version:
ovmf 2f2c51acfb70efe3dd020
flight 134039 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134039/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On Wed, 2019-03-27 at 18:06 +0100, Juergen Gross wrote:
> On 27/03/2019 17:58, Jan Beulich wrote:
> > > > >
> > Well, of course nothing's going to run on that CPU anymore.
> > But vCPU-s may still have associations with it, so what I'm
> > worried about is e.g. something finding v->processor point
On Mon, 2019-03-18 at 14:11 +0100, Juergen Gross wrote:
> Today there is special handling in cpu_disable_scheduler() for
> suspend
> by forcing all vcpus to the boot cpu. In fact there is no need for
> that
> as during resume the vcpus are put on the correct cpus again.
>
> So we can just omit the
Convert the xenfs filesystem to the new internal mount API as the old
one will be obsoleted and removed. This allows greater flexibility in
communication of mount parameters between userspace, the VFS and the
filesystem.
See Documentation/filesystems/mount_api.txt for more information.
Signed-of
flight 134140 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134140/
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
This run is configured for baseline tests only.
flight 83833 ovmf real [real]
http://osstest.xensource.com/osstest/logs/83833/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
flight 134117 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134117/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
1 - 100 of 102 matches
Mail list logo
