On 2019/4/1 16:36, Jan Beulich wrote:
On 30.03.19 at 11:42, wrote:
@@ -876,6 +877,10 @@ static int __init vpmu_init(void)
if ( amd_vpmu_init() )
vpmu_mode = XENPMU_MODE_OFF;
break;
+case X86_VENDOR_HYGON:
+if ( hygon_vpmu_init() )
+ vpmu_mo
On 2019/4/1 16:41, Jan Beulich wrote:
On 30.03.19 at 11:42, wrote:
There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.
I think it would have been nice if you had mentioned the real
reason why y
This is a note to let you know that I've just added the patch titled
x86/asm: Rewrite sync_core() to use IRET-to-self
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
x86-asm
This is a note to let you know that I've just added the patch titled
x86/asm: Rewrite sync_core() to use IRET-to-self
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
x86-asm
flight 134258 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134258/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 06b019117682c0d91074b4368e37acdd48f026f4
baseline version:
freebsd 8b558001903
On 4/1/19 9:35 AM, Juergen Gross wrote:
On 22/03/2019 08:37, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
camera driver which extends Xen's reach multimedia capabilities even
farther enabling it for video conferencing, In
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.
While at it avoid side effects from using BUG_ON() by not using
cpu_online(cpu) as a parameter.
Signed-off-by: Jue
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.
It should be noted that there is a potential change in behaviour as
the percpu areas are no longer zeroed out during suspend/resume.
cpu_disable_scheduler() is being called from __cpu_disable() today.
There is no need to execute it on the cpu just being disabled, so use
the CPU_DEAD case of the cpu notifier chain. Moving the call out of
stop_machine() context is fine, as we just need to hold the domain RCU
lock and need the sche
Especially in the scheduler area (schedule.c, cpupool.c) there is a
rather complex handling involved when doing suspend and resume.
This can be simplified a lot by not performing a complete cpu down and
up cycle for the non-boot cpus, but keeping the pure software related
state and freeing it only
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 in order to know which resources are
available then.
Signed-off-by: Juergen Gross
Reviewed-by: Dario Faggioli
Reviewed-by: Ge
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
Reviewed-by: George Dunlap
Reviewed-by: Dario Faggioli
---
V2:
- add comment (George Dunlap)
---
xen/common/cpupool.c | 131 +
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 call of cpu_disable_scheduler() when offlining
a cpu due to suspend a
flight 134255 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134255/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
Hi all,
based on the doodle poll, we are changing the community call day to the first
Thursday of each month.
Please propose topics by either editing the running agenda document at
https://docs.google.com/document/d/1B279exjoLW1-7aL4Y-dxtS8NY-EUwJ7uTt8qEKWAmFY/edit#heading
or by replying to th
This run is configured for baseline tests only.
flight 83856 ovmf real [real]
http://osstest.xensource.com/osstest/logs/83856/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 28, 2019 10:55 PM
>
> Move this into iommu_hardware_setup() and make that function non-
> inline. Move its declaration into common code.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
__
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, March 29, 2019 5:13 PM
>
> >>> On 28.03.19 at 18:37, wrote:
> > On 28/03/2019 14:53, Jan Beulich wrote:
> >> @@ -35,6 +35,8 @@ void print_vtd_entries(struct iommu *iom
> >> keyhandler_fn_t vtd_dump_iommu_info;
> >>
> >> bool intel_i
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 28, 2019 10:52 PM
>
> Introduce a respective element in struct iommu_init_ops.
>
> Take the liberty and also switch intel_iommu_supports_eim() to bool/
> true/false, to fully match the hook's type.
>
> Signed-off-by: Jan Beul
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 28, 2019 10:52 PM
>
> Do away with the CPU vendor dependency, and set the init ops pointer
> based on what ACPI tables have been found.
>
> Also take the opportunity and add __read_mostly to iommu_ops.
>
> Signed-off-by: Jan
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 28, 2019 10:49 PM
>
> I'm in particular after getting rid of asm/apicdef.h, but there are more
> no longer (or perhaps never having been) used ones.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
__
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, March 28, 2019 3:53 AM
>
> This has been problematic since its introduction in Xen 4.3
>
> Signed-off-by: Andrew Cooper
Acked-by: Kevin Tian
___
Xen-devel mailing list
Xen-dev
On Mon, Mar 25, 2019 at 09:38:21AM +, Sergey Dyasli wrote:
>On 11/03/2019 07:57, Chao Gao wrote:
>> This patch provides a tool for late microcode update.
>>
>> Signed-off-by: Konrad Rzeszutek Wilk
>> Signed-off-by: Chao Gao
>> ---
>> tools/libxc/include/xenctrl.h | 1 +
>> tools/libxc/xc_m
flight 134251 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134251/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
flight 134254 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134254/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1c27ec42363515bda97468dccf57a01c6e66d01e
baseline version:
ovmf 8028f03032182f2c72e76
flight 134272 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134272/
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 Mon, 1 Apr 2019, Wei Liu wrote:
> Wei Liu (4):
> pygrub: fix message in grub parser
> pygrub/grub: always use integer for default entry
> pygrub: decode string in Python 3
> tools/ocaml: make python scripts 2 and 3 compatible
>
> tools/ocaml/libs/xentoollog/genlevels.py | 5 -
> tools/o
Den 01.04.2019 11:34, skrev Kevin Wolf:
Yes, for 512 accesses on native 4k disks with O_DIRECT, the QEMU block
layer performs the necessary RMW. Of course, it still comes with a
performance penalty, so you want to avoid such setups, but they do work.
I suspect that the approximately 1/10 -th
Hello.
On Mon, 1 Apr 2019, Jan Beulich wrote:
On 31.03.19 at 10:11, wrote:
There is problem in PCI device allocation algorithm (pci_setup()).
Algorithm allocates PCI BAR sorted by size and this allows
mixed allocation of prefetchable and non-prefetchable PCI MEM BAR.
This leads to wrong config
Hi,
On 4/1/19 5:00 PM, Juergen Gross wrote:
On 01/04/2019 17:15, Julien Grall wrote:
Hi,
On 4/1/19 3:23 PM, Juergen Gross wrote:
On 01/04/2019 16:01, Julien Grall wrote:
Hi,
On 4/1/19 2:33 PM, Juergen Gross wrote:
On 01/04/2019 15:21, Julien Grall wrote:
Hi Juergen,
On 4/1/19 11:37 AM, J
flight 133953 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133953/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 128858
test-amd64-i386-free
On 01/04/2019 09:27, Jan Beulich wrote:
On 29.03.19 at 17:57, wrote:
>> timer_softirq_action() realloc's itself a larger timer heap whenever
>> necessary, which includes bootstrapping from the empty dummy_heap. Nothing
>> ever freed this allocation.
>>
>> CPU hot unplug and plug has the side
On Mon, Apr 01, 2019 at 01:17:19PM +0100, Paul Durrant wrote:
> 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
flight 134266 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134266/
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 1 Apr 2019, at 11:32, Wei Liu wrote:
>
> 1. Explicitly import reduce because that's required in 3.
> 2. Change print to function.
> 3. Eliminate invocations of has_key.
>
> Signed-off-by: M A Young
> Signed-off-by: Wei Liu
Acked-by: Christian Lindig
_
Hi all,
I'm trying to compile RELEASE-4.12.0 branch with --enable-githttp on a
network that blocks normal git accesses and I encountered the
following failures:
fatal: clone of 'git://git.qemu.org/capstone.git' into submodule path
'/data/src/xen/tools/qemu-xen-dir-remote/capstone' failed
Failed to
On 01/04/2019 11:32, Wei Liu wrote:
> 1. Explicitly import reduce because that's required in 3.
> 2. Change print to function.
> 3. Eliminate invocations of has_key.
>
> Signed-off-by: M A Young
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
___
On 01/04/2019 11:32, Wei Liu wrote:
> The original code set the default to either a string or an integer
> (0) and relies on a Python 2 specific behaviour to work (integer is
> allowed to be compared to string in Python 2 but not 3).
>
> Always use integer. The caller (pygrub) already has code to h
On 01/04/2019 11:32, Wei Liu wrote:
> String is unicode in 3 but bytes in 2. We need to call decode function
> when using Python 3.
>
> Reported-by: M A Young
> Signed-off-by: Wei Liu
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists
On 01/04/2019 11:32, Wei Liu wrote:
> The code suggests 0 is allowed. Zero is not a positive number.
>
> Signed-off-by: Wei Liu
I suspect you are opening a can of number theory worms with that commit
message, but the overall change is an improvement.
Acked-by: Andrew Cooper
___
On 01/04/2019 16:12, Jan Beulich wrote:
On 01.04.19 at 16:04, wrote:
>> On 29/03/2019 09:39, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -8547,6 +8547,9 @@ x86_emulate(
>>> invoke_stub("", "", "+m" (mask)
flight 134207 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134207/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
build-arm64-pvops
On 01/04/2019 17:15, Julien Grall wrote:
> Hi,
>
> On 4/1/19 3:23 PM, Juergen Gross wrote:
>> On 01/04/2019 16:01, Julien Grall wrote:
>>> Hi,
>>>
>>> On 4/1/19 2:33 PM, Juergen Gross wrote:
On 01/04/2019 15:21, Julien Grall wrote:
> Hi Juergen,
>
> On 4/1/19 11:37 AM, Juergen Gro
flight 134242 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134242/
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 01/04/2019 15:55, Jan Beulich wrote:
>
>> Secondly, when a guest executes CPUID, this doesn't
>> typically result in Xen executing a CPUID instruction in practice.
> Wait - this is true for DomU, but used to be false for (PV) Dom0,
> until you've switched over from pv_cpuid() to guest_cpuid().
Dear All,
this is a quick reminder that the CfP for the developer summit is approaching.
The CfP for talks (aka morning sessions is on April 12th). We are also
considering to allocate a day dedicated to embedded and safety related topics
following last week's automotive meeting. The link for su
Hi,
On 4/1/19 3:23 PM, Juergen Gross wrote:
On 01/04/2019 16:01, Julien Grall wrote:
Hi,
On 4/1/19 2:33 PM, Juergen Gross wrote:
On 01/04/2019 15:21, Julien Grall wrote:
Hi Juergen,
On 4/1/19 11:37 AM, Juergen Gross wrote:
On 01/04/2019 12:29, Julien Grall wrote:
Hi,
On 4/1/19 10:40 AM,
On Mon, 2019-04-01 at 09:19 +0100, Andrew Cooper wrote:
> On 01/04/2019 08:05, Dario Faggioli wrote:
> > On Mon, 2019-04-01 at 08:06 +0200, Juergen Gross wrote:
> > > The
> > > wrappers could then call the related specific scheduler function
> > > based
> > > on the scheduler Id using a chain of if
>>> On 01.04.19 at 16:04, wrote:
> On 29/03/2019 09:39, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -8547,6 +8547,9 @@ x86_emulate(
>> invoke_stub("", "", "+m" (mask) : "a" (&mask));
>> put_stub(stub);
>
>>> On 01.04.19 at 16:14, wrote:
> On 29/03/2019 10:56, Jan Beulich wrote:
> On 29.03.19 at 11:02, wrote:
>>> On 29/03/2019 09:36, Jan Beulich wrote:
I'd like to put up the other option then: Rather than using
_get_fpu() (and in particular the read_xcr() and read_cr() hooks)
we
>>> On 01.04.19 at 16:01, wrote:
> There are a number of bugs. There are no read/write hooks on the HVM side, so
> guest accesses fall into the "read/write-discard" defaults, which bypass the
> correct faulting behaviour and the Intel special case.
>
> For the PV side, writes are discarded (agai
On 29/03/2019 10:56, Jan Beulich wrote:
On 29.03.19 at 11:02, wrote:
>> On 29/03/2019 09:36, Jan Beulich wrote:
>>> I'd like to put up the other option then: Rather than using
>>> _get_fpu() (and in particular the read_xcr() and read_cr() hooks)
>>> we could read the real XCR0 here. After all
On 01/04/2019 16:01, Julien Grall wrote:
> Hi,
>
> On 4/1/19 2:33 PM, Juergen Gross wrote:
>> On 01/04/2019 15:21, Julien Grall wrote:
>>> Hi Juergen,
>>>
>>> On 4/1/19 11:37 AM, Juergen Gross wrote:
On 01/04/2019 12:29, Julien Grall wrote:
> Hi,
>
> On 4/1/19 10:40 AM, Juergen Gr
On 29/03/2019 09:39, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -8547,6 +8547,9 @@ x86_emulate(
> invoke_stub("", "", "+m" (mask) : "a" (&mask));
> put_stub(stub);
>
> +if ( rc != X86EMUL_OKAY )
>
There are a number of bugs. There are no read/write hooks on the HVM side, so
guest accesses fall into the "read/write-discard" defaults, which bypass the
correct faulting behaviour and the Intel special case.
For the PV side, writes are discarded (again, bypassing proper faulting),
except for a
Hi,
On 4/1/19 2:33 PM, Juergen Gross wrote:
On 01/04/2019 15:21, Julien Grall wrote:
Hi Juergen,
On 4/1/19 11:37 AM, Juergen Gross wrote:
On 01/04/2019 12:29, Julien Grall wrote:
Hi,
On 4/1/19 10:40 AM, Juergen Gross wrote:
On 01/04/2019 11:21, Julien Grall wrote:
Hi,
On 3/29/19 3:08 PM,
>>> On 01.04.19 at 14:35, wrote:
> On 01/04/2019 13:21, Jan Beulich wrote:
> On 01.04.19 at 12:09, wrote:
>>> 3) cpumask_weight() is a surprisingly expensive function, and we use it all
>>>over the place. It will almost certainly benefit from the use of popcnt.
>> FTR this was something
flight 134261 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134261/
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 Mon, Apr 01, 2019 at 11:19:19AM +0100, Sergey Dyasli wrote:
>On 25/03/2019 17:08, Jan Beulich wrote:
> On 25.03.19 at 12:12, wrote:
>>> Currently cpu_sig struct is not updated during boot when either:
>>>
>>> 1. ucode_scan is set to false (e.g. no "ucode=scan" in cmdline)
>>> 2. ini
On Mon, 2019-04-01 at 11:09 +0100, Andrew Cooper wrote:
> The is_pinned field is rather odd.
>
Indeed. And I'm very, very happy to see it going away.
> Signed-off-by: Andrew Cooper
>
Reviewed-by: Dario Faggioli
Regards,
Dario
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualizat
On 01/04/2019 15:21, Julien Grall wrote:
> Hi Juergen,
>
> On 4/1/19 11:37 AM, Juergen Gross wrote:
>> On 01/04/2019 12:29, Julien Grall wrote:
>>> Hi,
>>>
>>> On 4/1/19 10:40 AM, Juergen Gross wrote:
On 01/04/2019 11:21, Julien Grall wrote:
> Hi,
>
> On 3/29/19 3:08 PM, Juergen G
Hi Juergen,
On 4/1/19 11:37 AM, Juergen Gross wrote:
On 01/04/2019 12:29, Julien Grall wrote:
Hi,
On 4/1/19 10:40 AM, Juergen Gross wrote:
On 01/04/2019 11:21, Julien Grall wrote:
Hi,
On 3/29/19 3:08 PM, Juergen Gross wrote:
cpu_disable_scheduler() is being called from __cpu_disable() toda
On 03/21/2019 12:03 PM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On 03/20/2019 09:08 PM, Gustavo A. R. Silva wrote:
>> Hi all,
>>
>> Friendly ping:
>>
>> Who can take this?
>
> I'll take this for v5.2.
Patch queued for v5.2, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D I
flight 134201 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134201/
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 01/04/2019 13:21, Jan Beulich wrote:
On 01.04.19 at 12:09, wrote:
>> 3) cpumask_weight() is a surprisingly expensive function, and we use it all
>>over the place. It will almost certainly benefit from the use of popcnt.
> FTR this was something I was meaning to possibly do once the BM
> On 15 Mar 2019, at 03:00, Jan Beulich wrote:
>
On 14.03.19 at 18:22, wrote:
>> Options are:
>> a) Someone steps up and does the meeting either next week or the week after
>> b) Skip the March meeting
>> c) Skip the March meeting and restart April 4 and have the meeting the 1st
>> Thu
>>> On 01.04.19 at 12:09, wrote:
> 3) cpumask_weight() is a surprisingly expensive function, and we use it all
>over the place. It will almost certainly benefit from the use of popcnt.
FTR this was something I was meaning to possibly do once the BMI2
alternatives patching series would have b
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."
Commit fcab2b464e06 "xen: ad
>>> On 01.04.19 at 12:44, wrote:
>> On Apr 1, 2019, at 8:46 AM, Jan Beulich wrote:
>> +/*
>> + * Call this function from hooks potentially altering machine state into
>> + * something that's not architecturally valid, yet which - as per above -
>> + * the emulator relies on.
>> + */
>> +static bo
Hi Lukas,
You sent this patch twice. Is there any difference between the two?
On 3/27/19 7:19 AM, Lukas Juenger wrote:
Xen's vGIC implementation supports a maximum number of 992 IRQ lines.
NIT: The correct term is Interrupt Lines.
GICv2 specification allows for 1020 IRQ lines.
This is comm
On 01/04/2019 11:39, Wei Liu wrote:
> Signed-off-by: Wei Liu
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
> On Apr 1, 2019, at 8:46 AM, Jan Beulich wrote:
>
> This is to accompany sanitize_input(). Just like for initial state we
> want to have state between two emulated insns sane, at least as far as
> assumptions in the main emulator go. Do minimal checking after segment
> register, CR, and MSR wr
Signed-off-by: Wei Liu
---
tools/xenmon/xenmon.py | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/xenmon/xenmon.py b/tools/xenmon/xenmon.py
index 2a948cd48a..175eacd2cb 100644
--- a/tools/xenmon/xenmon.py
+++ b/tools/xenmon/xenmon.py
@@ -23,6 +23,8 @@
# along
On 01/04/2019 12:29, Julien Grall wrote:
> Hi,
>
> On 4/1/19 10:40 AM, Juergen Gross wrote:
>> On 01/04/2019 11:21, Julien Grall wrote:
>>> Hi,
>>>
>>> On 3/29/19 3:08 PM, Juergen Gross wrote:
cpu_disable_scheduler() is being called from __cpu_disable() today.
There is no need to execute
Hi Juergen,
On 3/28/19 12:06 PM, Juergen Gross wrote:
cpu_disable_scheduler() is being called from __cpu_disable() today.
There is no need to execute it on the cpu just being disabled, so use
the CPU_DEAD case of the cpu notifier chain. Moving the call out of
stop_machine() context is fine, as w
flight 83853 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/83853/
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
String is unicode in 3 but bytes in 2. We need to call decode function
when using Python 3.
Reported-by: M A Young
Signed-off-by: Wei Liu
---
tools/pygrub/src/pygrub | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
index d
The original code set the default to either a string or an integer
(0) and relies on a Python 2 specific behaviour to work (integer is
allowed to be compared to string in Python 2 but not 3).
Always use integer. The caller (pygrub) already has code to handle
that.
Reported-by: M A Young
Signed-o
Wei Liu (4):
pygrub: fix message in grub parser
pygrub/grub: always use integer for default entry
pygrub: decode string in Python 3
tools/ocaml: make python scripts 2 and 3 compatible
tools/ocaml/libs/xentoollog/genlevels.py | 5 -
tools/ocaml/libs/xl/genwrap.py | 17 ++
1. Explicitly import reduce because that's required in 3.
2. Change print to function.
3. Eliminate invocations of has_key.
Signed-off-by: M A Young
Signed-off-by: Wei Liu
---
tools/ocaml/libs/xentoollog/genlevels.py | 5 -
tools/ocaml/libs/xl/genwrap.py | 17 ++---
2
The code suggests 0 is allowed. Zero is not a positive number.
Signed-off-by: Wei Liu
---
Backport candadiate.
---
tools/pygrub/src/GrubConf.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/GrubConf.py
index f8d3799dc0..0204d4
Hi,
On 4/1/19 10:40 AM, Juergen Gross wrote:
On 01/04/2019 11:21, Julien Grall wrote:
Hi,
On 3/29/19 3:08 PM, Juergen Gross wrote:
cpu_disable_scheduler() is being called from __cpu_disable() today.
There is no need to execute it on the cpu just being disabled, so use
the CPU_DEAD case of the
On 25/03/2019 17:08, Jan Beulich wrote:
On 25.03.19 at 12:12, wrote:
>> Currently cpu_sig struct is not updated during boot when either:
>>
>> 1. ucode_scan is set to false (e.g. no "ucode=scan" in cmdline)
>> 2. initrd does not contain a microcode blob
>
> What about "ucode="?
Yes,
flight 134250 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134250/
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
The is_pinned field is rather odd. It can only be activated with the
"dom0_vcpus_pin" command line option, and causes dom0 (or the late hwdom) to
have its vcpus identity pinned to pcpus.
Having dom0_vcpus_pin active disallows the use of vcpu_set_hard_affinity().
However, when a pcpu is hot unplug
On Wed, Mar 27, 2019 at 01:36:10AM +0100, Hans van Kranenburg wrote:
> 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.orig2019-03-24
> >> 22:44:05.503582025 +
> >> +++ xen-
On Mon, Apr 01, 2019 at 10:59:05AM +0100, M A Young wrote:
>
>
> On Mon, 1 Apr 2019, Wei Liu wrote:
>
> > On Tue, Mar 26, 2019 at 10:06:48PM +0100, Hans van Kranenburg wrote:
> > >
> > > Python 3 no longer allows comparing string and int, because it doesn't
> > > make sense.
> > >
> > > == sor
On Mon, 1 Apr 2019, Wei Liu wrote:
> On Tue, Mar 26, 2019 at 10:06:48PM +0100, Hans van Kranenburg wrote:
> >
> > Python 3 no longer allows comparing string and int, because it doesn't
> > make sense.
> >
> > == sorted([1,2,3,'a','b','c'])
> > Traceback (most recent call last):
> > File "",
flight 134237 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134237/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
> -Original Message-
[snip]
> > >
> > > The old implementation has the sector size hardcoded:
> > >
> > > #define BLOCK_SIZE 512
> > >
> > > Whereas the qdevified version uses DEFINE_BLOCK_PROPERTIES(), which
> > > includes user-visible options for logical/physical_block_size.
> > >
>
On 01/04/2019 10:50, Andrew Cooper wrote:
> On 29/03/2019 15:09, Juergen Gross wrote:
>> Make sure the number of vcpus is always a multiple of the scheduling
>> granularity. Note that we don't support a scheduling granularity above
>> one on ARM.
>
> I'm afraid that I don't think this is a clever
On Tue, Mar 26, 2019 at 10:06:48PM +0100, Hans van Kranenburg wrote:
>
> Python 3 no longer allows comparing string and int, because it doesn't
> make sense.
>
> == sorted([1,2,3,'a','b','c'])
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: unorderable types: str() < in
On 01/04/2019 11:21, Julien Grall wrote:
> Hi,
>
> On 3/29/19 3:08 PM, Juergen Gross wrote:
>> cpu_disable_scheduler() is being called from __cpu_disable() today.
>> There is no need to execute it on the cpu just being disabled, so use
>> the CPU_DEAD case of the cpu notifier chain. Moving the cal
Am 01.04.2019 um 11:01 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Kevin Wolf [mailto:kw...@redhat.com]
> > Sent: 28 March 2019 11:56
> > To: Andrew Cooper
> > Cc: Anthony Perard ; Paul Durrant
> > ; xen-
> > de...@lists.xenproject.org; qemu-bl...@nongnu.org; qemu-de...
Hi,
On 3/29/19 3:08 PM, Juergen Gross wrote:
cpu_disable_scheduler() is being called from __cpu_disable() today.
There is no need to execute it on the cpu just being disabled, so use
the CPU_DEAD case of the cpu notifier chain. Moving the call out of
stop_machine() context is fine, as we just ne
Ping?
On Thu, Feb 28, 2019 at 01:44:43PM +, Wei Liu wrote:
> We have a requirement to make each commit buildable in xen.git. Put this
> into a test in Gitlab CI.
>
> Wei Liu (5):
> automation: allow build-test.sh to run in detached HEAD state
> automation: set ret for potential error in b
On Tue, Mar 26, 2019 at 10:06:48PM +0100, Hans van Kranenburg wrote:
> 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:
>
On 01/04/2019 10:56, Ian Jackson wrote:
> CC: Lars Kurth
> CC: Juergen Gross
> Signed-off-by: Ian Jackson
> ---
> SUPPORT.md | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 19fc8d7533..d4173d70ad 100644
> --- a/SUPPORT.md
> +++ b
> -Original Message-
> From: Kevin Wolf [mailto:kw...@redhat.com]
> Sent: 28 March 2019 11:56
> To: Andrew Cooper
> Cc: Anthony Perard ; Paul Durrant
> ; xen-
> de...@lists.xenproject.org; qemu-bl...@nongnu.org; qemu-de...@nongnu.org;
> Stefano Stabellini
> ; Max Reitz ; Stefan Hajnoczi
>>> On 01.04.19 at 10:56, wrote:
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -9,10 +9,10 @@ for the definitions of the support status levels etc.
>
> # Release Support
>
> -Xen-Version: 4.12-rc
> -Initial-Release: n/a
> -Supported-Until: TBD
> -Security-Support-Until: Unrelease
1 - 100 of 126 matches
Mail list logo
