>>> On 25.03.19 at 18:00, wrote:
> I removed the "maxcpus=1" and attempted seven (7) boots.
> There were minor variations, they do not seem to get
> past the first additional processor. Below is a summary.
And with "maxcpus=1" in place, is it as stable hanging when trying
to bring up the 3rd AP?
>>> On 25.03.19 at 18:36, wrote:
> On 25/03/2019 15:24, 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
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
> > and with a guest kernel having TIMER_SLOP set to 1000 (arbitrary
> > small
> > value :).
> > All the experiments
On 3/25/19 8:54 PM, Danux wrote:
Hi,
Hello,
When adding altp2m=1 argument to xen,xen-bootargs via DTB, I can see the
parameter passed via xl info:
xen_commandline : console=dtuart dtuart=serial0 dom0_mem=1G
bootscrub=0 maxcpus=1 timer_slop=0*altp2m=1*
However, I got an error like
flight 134062 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134062/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 134066 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134066/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 17b9e44c40f1d40251c09600e89ad6c1752318bf
baseline version:
freebsd d77cb4a0221
On Mon, Mar 25, 2019 at 02:51:46PM +, Andrew Cooper wrote:
> On 25/03/2019 11:33, Wei Liu wrote:
> > On Mon, Mar 25, 2019 at 11:21:44AM +, Wei Liu wrote:
> >> On Fri, Mar 22, 2019 at 11:13:40AM +, Andrew Cooper wrote:
> >>> CentOS 6 is probably the most frequently broken build, so addin
Hi all,
On Tue, 26 Mar 2019 10:13:32 +0100
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
> > > and with a guest kernel having
On Tue, Mar 26, 2019 at 12:12:56PM +0100, luca abeni wrote:
> Hi all,
>
> On Tue, 26 Mar 2019 10:13:32 +0100
> 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 meas
>>> On 21.03.19 at 13:21, wrote:
> Also introduce constants for the vendor strings in CPUID leaf 0.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
albeit I'd appreciate if this was committed together with an actual
user (other than the testsuite one) of the new function, and
despite
>>> On 21.03.19 at 13:21, wrote:
> get_cpu_vendor() tries to do a number of things, and ends up doing none of
> them well.
>
> For calculating the vendor itself, use x86_cpuid_lookup_vendor() which is
> implemented in a far more efficient manner than looping over cpu_devs[].
Well, yes, the new l
>>> On 21.03.19 at 13:21, wrote:
> This doesn't address any of the assumptions that "anything which isn't AMD is
> Intel". This logic is expected to be replaced wholesale with libx86 in the
> longterm.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
__
This is now fixed
Lars
> On 25 Mar 2019, at 22:41, Lars Kurth wrote:
>
> Marek,
> thanks for pointing this out. I will fix this tomorrow
> Lars
>
>> On 21 Mar 2019, at 23:11, Marek Marczykowski-Górecki
>> wrote:
>>
>> Signed PGP part
>> Hi,
>>
>> Looks like the new website doesn't list Xen
>>> On 21.03.19 at 13:21, wrote:
> When filling a policy, either from CPUID or an incomming leaf stream,
> recalculate the synthesised vendor value. All callers are expected to want
> this behaviour.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
with one question:
> @@ -141,6 +14
On 26/03/2019 12:20, Jan Beulich wrote:
On 21.03.19 at 13:21, wrote:
>> When filling a policy, either from CPUID or an incomming leaf stream,
>> recalculate the synthesised vendor value. All callers are expected to want
>> this behaviour.
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Ja
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
in the same way that it did in previous releases.
>>> I wonder whether you've taken
flight 134087 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134087/
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 26/03/2019 11:52, Jan Beulich wrote:
On 21.03.19 at 13:21, wrote:
>> Also introduce constants for the vendor strings in CPUID leaf 0.
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
> albeit I'd appreciate if this was committed together with an actual
> user (other than the
>>> On 26.03.19 at 07:45, wrote:
> Extend smbios type 2 struct to match specification, add support to
> override strings from toolstack.
>
> Signed-off-by: Xin Li
>
> ---
> CC: Igor Druzhinin
> CC: Sergey Dyasli
> CC: Andrew Cooper
I wonder why I have not been Cc-ed.
> @@ -518,7 +520,67 @@
On Mon, Mar 25, 2019 at 10:20:05PM +, YOUNG, MICHAEL A. wrote:
> I have been testing the python3 changes committed to xen and found a few
> issues. There are a couple of ocaml python build scripts that don't work
> for me with python3, and I needed a few fixes to get pygrub to work,
> mostly
Linus,
On Mon 2019-03-25 21:32:28, Sakari Ailus wrote:
> %pF and %pf are functionally equivalent to %pS and %ps conversion
> specifiers. The former are deprecated, therefore switch the current users
> to use the preferred variant.
>
> The changes have been produced by the following command:
>
>
>>> 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
> in the same way that it did in previous rel
On Tue, Mar 26, 2019 at 01:16:35PM +, Wei Liu wrote:
> On Mon, Mar 25, 2019 at 10:20:05PM +, YOUNG, MICHAEL A. wrote:
> > if ty.init_fn is not None:
> > --- xen-4.12.0-rc6/tools/pygrub/src/GrubConf.py.orig2019-03-24
> > 22:44:05.502581989 +
> > +++ xen-4.12.0-rc6/tools
>>> On 26.03.19 at 14:11, wrote:
> On 26/03/2019 11:52, Jan Beulich wrote:
> On 21.03.19 at 13:21, wrote:
>>> Also introduce constants for the vendor strings in CPUID leaf 0.
>>>
>>> Signed-off-by: Andrew Cooper
>> Reviewed-by: Jan Beulich
>> albeit I'd appreciate if this was committed toge
On 26/03/2019 15:07, Jan Beulich wrote:
On 26.03.19 at 14:11, wrote:
>> On 26/03/2019 11:52, Jan Beulich wrote:
>> On 21.03.19 at 13:21, wrote:
Also introduce constants for the vendor strings in CPUID leaf 0.
Signed-off-by: Andrew Cooper
>>> Reviewed-by: Jan Beulich
>>>
CentOS 6 is probably the most frequently broken build, so adding it to CI
would be a very good move.
One problem is that CentOS 6 comes with Python 2.6, and Qemu requires 2.7.
There appear to be no sensible ways to get Python 2.7 into a CentOS 6
environments, so modify the build script to skip the
>>> 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
> modified to use a pointer to uint32_t instead of
On 26/03/2019 15: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 26.03.19 at 15:47, wrote:
> On 26/03/2019 15: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
On Tue, Mar 26, 2019 at 02:23:03PM +, Andrew Cooper wrote:
> CentOS 6 is probably the most frequently broken build, so adding it to CI
> would be a very good move.
>
> One problem is that CentOS 6 comes with Python 2.6, and Qemu requires 2.7.
> There appear to be no sensible ways to get Python
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 25.03.19 at 14:29, wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -32,11 +32,6 @@
> static char __initdata opt_famrev[14];
> string_param("cpuid_mask_cpu", opt_famrev);
>
> -static unsigned int __initdata opt_cpuid_mask_l7s0_eax = ~0u;
> -integer_param("cpuid_
flight 134071 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134071/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2f2c51acfb70efe3dd02022ca09dd853601d8acd
baseline version:
ovmf 210bd16aff81f6746033d
>>> 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 the data you enter into the table in the later patch. IOW
>> my fundamental concern di
>>> 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_init(void)
Despite it having been me (I think) t
>>> On 21.03.19 at 13:24, wrote:
> @@ -216,6 +218,10 @@ DEFINE_PER_CPU(struct cpu_signature, cpu_sig);
> */
> static atomic_t cpu_in, cpu_out;
>
> +static uint32_t application_strategy;
> +/* The next CPU to perform a ucode update */
> +static int next_cpu;
unsigned int (twice).
> --- a/xen/
On 26/03/2019 12:08, Jan Beulich wrote:
On 21.03.19 at 13:21, wrote:
>> get_cpu_vendor() tries to do a number of things, and ends up doing none of
>> them well.
>>
>> For calculating the vendor itself, use x86_cpuid_lookup_vendor() which is
>> implemented in a far more efficient manner than l
On 3/26/2019 1:04 AM, Jan Beulich wrote:
On 25.03.19 at 18:00, wrote:
I removed the "maxcpus=1" and attempted seven (7) boots.
There were minor variations, they do not seem to get
past the first additional processor. Below is a summary.
And with "maxcpus=1" in place, is it as stable hanging
On Tue, 26 Mar 2019, Wei Liu wrote:
> On Tue, Mar 26, 2019 at 01:16:35PM +, Wei Liu wrote:
> > On Mon, Mar 25, 2019 at 10:20:05PM +, YOUNG, MICHAEL A. wrote:
> > > if ty.init_fn is not None:
> > > --- xen-4.12.0-rc6/tools/pygrub/src/GrubConf.py.orig 2019-03-24
> > > 22:44:05
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-freebsd10-i386
testid guest-saverestore
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://
flight 134069 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134069/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
This run is configured for baseline tests only.
flight 83827 ovmf real [real]
http://osstest.xensource.com/osstest/logs/83827/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
On 3/26/19 7:18 PM, M A Young wrote:
> On Tue, 26 Mar 2019, Wei Liu wrote:
>
>> On Tue, Mar 26, 2019 at 01:16:35PM +, Wei Liu wrote:
>>> On Mon, Mar 25, 2019 at 10:20:05PM +, YOUNG, MICHAEL A. wrote:
if ty.init_fn is not None:
--- xen-4.12.0-rc6/tools/pygrub/src/GrubConf
flight 134072 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134072/
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 134093 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134093/
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/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 the data you enter into the table in the
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
>>> and with a guest kernel having TIMER_SLOP set to 1000 (arbitrary
>>> sma
On 3/26/19 2:16 PM, Wei Liu wrote:
> On Mon, Mar 25, 2019 at 10:20:05PM +, YOUNG, MICHAEL A. wrote:
>> [...]
>> --- xen-4.12.0-rc6/tools/pygrub/src/pygrub.orig 2019-03-24
>> 22:44:05.503582025 +
>> +++ xen-4.12.0-rc6/tools/pygrub/src/pygrub 2019-03-24 22:48:24.446113809
>> +
>>
flight 134104 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134104/
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 134080 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134080/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 134038 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134038/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
flight 134097 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134097/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 134071
Tests which did not succee
flight 134083 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134083/
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 3/25/19 7:30 PM, Anchal Agarwal wrote:
On Fri, Mar 22, 2019 at 10:44:33AM +, Oleksandr Andrushchenko wrote:
On 3/20/19 5:50 AM, Munehisa Kamata wrote:
On 3/18/2019 3:02 AM, Oleksandr Andrushchenko wrote:
+Amazon
pls see inline
Hi Oleksandr,
Let me add some comments as the original aut
54 matches
Mail list logo
