On Fri, Aug 02, 2019 at 03:21:55PM +, Jan Beulich wrote:
>On 01.08.2019 12:22, Chao Gao wrote:
>> --- a/xen/arch/x86/microcode.c
>> +++ b/xen/arch/x86/microcode.c
>> @@ -277,6 +277,9 @@ static long do_microcode_update(void *_info)
>> if ( error )
>> info->error = error;
>>
>>
On Fri, Aug 02, 2019 at 02:46:58PM +, Jan Beulich wrote:
>On 01.08.2019 12:22, Chao Gao wrote:
>> +bool microcode_update_cache(struct microcode_patch *patch)
>> +{
>> +
>> +ASSERT(spin_is_locked(µcode_mutex));
>> +
>> +if ( !microcode_cache )
>> +microcode_cache = patch;
>> +
On Fri, Aug 02, 2019 at 03:40:55PM +, Jan Beulich wrote:
>On 01.08.2019 12:22, Chao Gao wrote:
>> --- a/xen/arch/x86/microcode.c
>> +++ b/xen/arch/x86/microcode.c
>> @@ -189,12 +189,20 @@ static DEFINE_SPINLOCK(microcode_mutex);
>>
>> DEFINE_PER_CPU(struct cpu_signature, cpu_sig);
>>
>>
Hello, all.
Forgot to mention that an additional patch from Xen staging is needed,
otherwise Xen may crash at the early stage:
ead6b9f78355e8d366e0c80c4a73fa7fbd6d26cc
"xen/arm: cpuerrata: Align a virtual address before unmap"
--
Regards,
Oleksandr Tyshchenko
flight 139703 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139703/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
test-amd64-i386-qemu
On 05/08/2019 08:58, Oleksandr wrote:
Hello, all.
Hi,
Forgot to mention that an additional patch from Xen staging is needed, otherwise
Xen may crash at the early stage:
ead6b9f78355e8d366e0c80c4a73fa7fbd6d26cc
"xen/arm: cpuerrata: Align a virtual address before unmap"
This patch is alre
Hi,
I have CCed one person from Donerworks. IIRC they have been using the IMX8 in
the past.
On 03/08/2019 21:54, Amit Tomer wrote:
I have seen multiple threads from you pointing at issues on the IMX.8. Have they
been resolved? Is this series enough to get Xen and Dom0 booting on the NXP
platf
In commit ac3f9a72141a48d40fabfff561d5a7dc0e1b810d:
For one, "no-xen" should not imply "no-eager-fpu", as "eager FPU" mode
is to guard guests, not Xen itself, which is also expressed so by
print_details().
So when spec-ctrl=pv=off,hvm=off; EAGER_FPU shouldn't be display in lines:
Curr
On 05/08/2019 09:54, Jin Nan Wang wrote:
> In commit ac3f9a72141a48d40fabfff561d5a7dc0e1b810d:
> For one, "no-xen" should not imply "no-eager-fpu", as "eager FPU" mode
> is to guard guests, not Xen itself, which is also expressed so by
> print_details().
>
> So when spec-ctrl=pv=off,hvm
On 02.08.2019 20:31, Andrew Cooper wrote:
> On 03/07/2019 11:47, Jan Beulich wrote:
> On 24.05.19 at 17:15, wrote:
>>> --- a/tools/tests/x86_emulator/Makefile
>>> +++ b/tools/tests/x86_emulator/Makefile
>>> @@ -149,7 +149,7 @@ $(addsuffix .h,$(TESTCASES)): %.h: %.c testcase.mk
>>> Makefile
>>
On 8/5/19 5:04 PM, Andrew Cooper wrote:
> On 05/08/2019 09:54, Jin Nan Wang wrote:
>> In commit ac3f9a72141a48d40fabfff561d5a7dc0e1b810d:
>> For one, "no-xen" should not imply "no-eager-fpu", as "eager FPU" mode
>> is to guard guests, not Xen itself, which is also expressed so by
>> pr
On 7/29/19 7:38 PM, Lars Kurth wrote:
> Hi everyone,
>
> adding committers, who would need to vote for or against the proposal. The
> title probably does not need an RFC, which is why no-one looked at it so far
>
> I think this is a great idea and I would want to welcome XCP-ng into the
> proje
On 05.08.2019 07:58, Chao Gao wrote:
> On Fri, Aug 02, 2019 at 01:29:14PM +, Jan Beulich wrote:
>> On 01.08.2019 12:22, Chao Gao wrote:
>>> --- a/xen/arch/x86/microcode_intel.c
>>> +++ b/xen/arch/x86/microcode_intel.c
>>> @@ -134,14 +134,35 @@ static int collect_cpu_info(unsigned int cpu_num,
On 05.08.2019 09:02, Chao Gao wrote:
> On Fri, Aug 02, 2019 at 02:46:58PM +, Jan Beulich wrote:
>> On 01.08.2019 12:22, Chao Gao wrote:
>>> +bool microcode_update_cache(struct microcode_patch *patch)
>>> +{
>>> +
>>> +ASSERT(spin_is_locked(µcode_mutex));
>>> +
>>> +if ( !microcode_cache
On 05.08.2019 09:36, Chao Gao wrote:
> On Fri, Aug 02, 2019 at 03:40:55PM +, Jan Beulich wrote:
>> On 01.08.2019 12:22, Chao Gao wrote:
>>> --- a/xen/arch/x86/microcode.c
>>> +++ b/xen/arch/x86/microcode.c
>>> @@ -189,12 +189,20 @@ static DEFINE_SPINLOCK(microcode_mutex);
>>>
>>>DEFINE_
Hi,
On 09/04/2019 12:42, Jan Beulich wrote:
On 09.04.19 at 13:26, wrote:
On 03/04/2019 14:04, Jan Beulich wrote:
Also please note the quotation used by the mentioned
existing doc comments, as well as a few other formal aspects
(like them also making clear what the return type is). I think
tha
On Sat, 2019-08-03 at 17:22 +0100, Andrew Cooper wrote:
> On 31/07/2019 17:58, Dario Faggioli wrote:
> >
> > Interestingly, in the past couple of days, a few build issues of
> > Xen,
> > qemu-xen and ipxe (at the commit that we were checking out) with
> > gcc
> > 9.1.1 where discovered and fixed.
On 02.08.2019 18:16, George Dunlap wrote:
> Commits ec83f825627 "mm.h: add helper function to test-and-clear
> _PGC_allocated" (and subsequent fix-up 44a887d021d "mm.h: fix BUG_ON()
> condition in put_page_alloc_ref()") introduced a BUG_ON() to detect
> unsafe behavior of callers.
>
> Unfortunatel
On 02.08.2019 18:39, Oleksandr Tyshchenko wrote:
> --- a/xen/common/xmalloc_tlsf.c
> +++ b/xen/common/xmalloc_tlsf.c
> @@ -610,6 +610,27 @@ void *_xzalloc(unsigned long size, unsigned long align)
> return p ? memset(p, 0, size) : p;
> }
>
> +void *_xrealloc(void *p, unsigned long new_siz
On 05.08.2019 11:40, Julien Grall wrote:
> Hi,
>
> On 09/04/2019 12:42, Jan Beulich wrote:
> On 09.04.19 at 13:26, wrote:
>>> On 03/04/2019 14:04, Jan Beulich wrote:
Also please note the quotation used by the mentioned
existing doc comments, as well as a few other formal aspects
>>>
Hi Jan,
On 05/08/2019 11:07, Jan Beulich wrote:
On 05.08.2019 11:40, Julien Grall wrote:
Hi,
On 09/04/2019 12:42, Jan Beulich wrote:
On 09.04.19 at 13:26, wrote:
On 03/04/2019 14:04, Jan Beulich wrote:
Also please note the quotation used by the mentioned
existing doc comments, as well as a
On 01.08.2019 12:22, Chao Gao wrote:
> Both are loading the cached patch. Since APs call the unified function,
> microcode_update_one(), during wakeup, the 'start_update' parameter
> which originally used to distinguish BSP and APs is redundant. So remove
> this parameter.
>
> Signed-off-by: Chao
On 05.08.2019 12:17, Julien Grall wrote:
> Hi Jan,
>
> On 05/08/2019 11:07, Jan Beulich wrote:
>> On 05.08.2019 11:40, Julien Grall wrote:
>>> Hi,
>>>
>>> On 09/04/2019 12:42, Jan Beulich wrote:
>>> On 09.04.19 at 13:26, wrote:
> On 03/04/2019 14:04, Jan Beulich wrote:
>> Also please
On 01.08.2019 12:22, Chao Gao wrote:
> @@ -234,6 +267,35 @@ bool microcode_update_cache(struct microcode_patch
> *patch)
> }
>
> /*
> + * Wait for a condition to be met with a timeout (us).
> + */
> +static int wait_for_condition(int (*func)(void *data), void *data,
> +
On 7/26/19 7:25 AM, Dario Faggioli wrote:
> If a vCPU is, or is going, offline we want it to be neither
> assigned to a pCPU, nor in the wait list, so:
> - if an offline vcpu is inserted (or migrated) it must not
> go on a pCPU, nor in the wait list;
> - if an offline vcpu is removed, we are sure
Hi. Thanks for looking into this. Sorry about the delay to the
review. I found it, unsent, while recovering a crashed mailreader
session...
George Dunlap writes ("[PATCH RFC 1/2] scripts: Add script to do the repetitive
bits of the release process"):
> With this script, once the main checks ar
On 11/26/18 9:31 AM, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
> ---
> v2: Drop signed-ness requirement.
>
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@ -88,6 +88,19 @@ Braces should be omitted for blocks with
> if ( condition )
> single_statement();
>
> +Types
> +-
> +
> +Use
Hi Stefano,
On 16/04/2019 21:33, Stefano Stabellini wrote:
On Tue, 2 Apr 2019, Julien Grall wrote:
After upgrading Debian to Buster, I have began to notice console
mangling when using zsh in Dom0. This is happenning because output sent by
zsh to the console may contain NULs in the middle of the
Functions make_timer_node and make_timer_domU_node are quite similar,
so it is better to consolidate them to avoid discrepancy.
This patch series achives this goal in two steps:
- Extend fdt_property_interrupts to deal with other domain than the hwdom.
- Consolidate make_timer_node and make_timer_
Functions make_timer_node and make_timer_domU_node are quite similar.
So it is better to consolidate them to avoid discrepancy.
The main difference between the functions is the timer interrupts used.
Keep the domU version for the compatible as it is simpler:
do not copy platform's 'compatible' pro
Extend fdt_property_interrupts to deal with other domain than the hwdom.
The prototype of fdt_property_interrupts() has been modified
to support both hwdom and domU in one function.
This is a preparatory for the next patch which consolidates
make_timer_node and make_timer_domU_node".
Original goa
On Mon, Aug 05, 2019 at 09:27:58AM +, Jan Beulich wrote:
>On 05.08.2019 07:58, Chao Gao wrote:
>> On Fri, Aug 02, 2019 at 01:29:14PM +, Jan Beulich wrote:
>>> On 01.08.2019 12:22, Chao Gao wrote:
--- a/xen/arch/x86/microcode_intel.c
+++ b/xen/arch/x86/microcode_intel.c
@@ -13
On 05.08.2019 13:51, Chao Gao wrote:
> On Mon, Aug 05, 2019 at 09:27:58AM +, Jan Beulich wrote:
>> On 05.08.2019 07:58, Chao Gao wrote:
>>> On Fri, Aug 02, 2019 at 01:29:14PM +, Jan Beulich wrote:
On 01.08.2019 12:22, Chao Gao wrote:
> --- a/xen/arch/x86/microcode_intel.c
> +++
* Add a dependency so the shim gets rebuilt when pvshim_defconfig changes.
* Default to the NULL scheduler now that it works with vcpu online/offline.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Dario Faggioli
v2:
* Drop MEM_ACCESS changes. x86 does
On 05.08.2019 12:58, George Dunlap wrote:
> On 11/26/18 9:31 AM, Jan Beulich wrote:
>> +Fixed width types should only be used when a fixed width quantity is
>> +meant (which for example may be a value read from or to be written to a
>> +register).
>
> I'm having trouble understanding the intent /
On Fri, Aug 02, 2019 at 06:06:14PM +0200, Vlastimil Babka wrote:
> The x86 version of get_user_pages_fast() relies on disabled interrupts to
> synchronize gup_pte_range() between gup_get_pte(ptep); and get_page() against
> a parallel munmap. The munmap side nulls the pte, then flushes TLBs, then
>
On 05.08.2019 13:52, Andrew Cooper wrote:
> * Add a dependency so the shim gets rebuilt when pvshim_defconfig changes.
> * Default to the NULL scheduler now that it works with vcpu online/offline.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
On Mon, Aug 05, 2019 at 09:38:00AM +, Jan Beulich wrote:
>On 05.08.2019 09:36, Chao Gao wrote:
>> On Fri, Aug 02, 2019 at 03:40:55PM +, Jan Beulich wrote:
>>> On 01.08.2019 12:22, Chao Gao wrote:
--- a/xen/arch/x86/microcode.c
+++ b/xen/arch/x86/microcode.c
@@ -189,12 +189,20
On 01.08.2019 12:22, Chao Gao wrote:
> @@ -283,37 +345,105 @@ static int microcode_update_cpu(const struct
> microcode_patch *patch)
> return err;
> }
>
> -static long do_microcode_update(void *patch)
> +static int do_microcode_update(void *patch)
> {
> -unsigned int cpu;
> +u
On 01.08.2019 12:22, Chao Gao wrote:
> @@ -439,12 +440,37 @@ static int do_microcode_update(void *patch)
> return ret;
> }
>
> +static int microcode_nmi_callback(const struct cpu_user_regs *regs, int cpu)
> +{
> +bool print = false;
> +
> +/* The first thread of a core is to load
This is a note to let you know that I've just added the patch titled
x86, mm, gup: prevent get_page() race with munmap in paravirt guest
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 pat
The current names, boot_cpu_{,compat_}gdt_table, have a table suffix which is
redundant with the T of GDT, and the cpu infix doesn't provide any meaningful
context. Drop them both.
Likewise, shorten the {,compat_}gdt{,_l1e} variables.
Finally, rename gdt_descr to boot_gdtr to more clearly identi
Split up the long asm block by commenting the logical subsections.
The movabs for obtaining __start_xen can be a rip-relative lea instead. This
has the added advantage that objdump can now cross reference it during
disassembly.
The stack handing is confusing to follow. %rsp is set up by reading
Various bits of cleanup intended to make the boot sequence clearer to follow,
and remove bits of asm which shouldn't be written in asm.
No changes to functionality.
Andrew Cooper (4):
x86/asm: Include msr-index.h rather than msr.h
x86/boot: Minor improvements to efi_arch_post_exit_boot()
x8
There is nothing interesting for assembly code in msr.h
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/boot/head.S | 2 +-
xen/arch/x86/x86_64/kexec_reloc.S | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/a
... where we can at least get the compiler to fill in the surrounding space
without having to do it manually. This also reults in the symbols having
proper type/size information in the debug symbols.
Reorder 'raw' in the seg_desc_t union to allow for easier initialisation.
Leave a comment explai
On 30.07.2019 16:42, Andrew Cooper wrote:
> c/s e9986b0dd "x86/vvmx: Simplify per-CPU memory allocations" had the wrong
> indirection on its pointer check in nvmx_cpu_up_prepare(), causing the
> VMCS-shadowing buffer never be allocated. Fix it.
>
> This in turn results in a massive quantity of lo
On 8/5/19 12:55 PM, Jan Beulich wrote:
> On 05.08.2019 12:58, George Dunlap wrote:
>> On 11/26/18 9:31 AM, Jan Beulich wrote:
>>> +Fixed width types should only be used when a fixed width quantity is
>>> +meant (which for example may be a value read from or to be written to a
>>> +register).
>>
>>
On Mon, Aug 05, 2019 at 10:43:16AM +, Jan Beulich wrote:
>On 01.08.2019 12:22, Chao Gao wrote:
>> @@ -234,6 +267,35 @@ bool microcode_update_cache(struct microcode_patch
>> *patch)
>> }
>>
>> /*
>> + * Wait for a condition to be met with a timeout (us).
>> + */
>> +static int wait_for_c
On 05/08/2019 13:52, Jan Beulich wrote:
> On 30.07.2019 16:42, Andrew Cooper wrote:
>> c/s e9986b0dd "x86/vvmx: Simplify per-CPU memory allocations" had the wrong
>> indirection on its pointer check in nvmx_cpu_up_prepare(), causing the
>> VMCS-shadowing buffer never be allocated. Fix it.
>>
>> Th
On 05.08.2019 15:01, George Dunlap wrote:
> On 8/5/19 12:55 PM, Jan Beulich wrote:
>> On 05.08.2019 12:58, George Dunlap wrote:
>>> On 11/26/18 9:31 AM, Jan Beulich wrote:
+Fixed width types should only be used when a fixed width quantity is
+meant (which for example may be a value read f
flight 139718 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139718/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1702e2ce5a5bc2eb4514f6b1c0d68927b920528a
baseline version:
ovmf afebc51547082faa080b3
At the moment, HYPERCALL_console_io is using signed int to describe the
command (@cmd) and the size of the buffer (@count).
* @cmd does not need to be signed this used as a set of named value.
None of them are negative. If new one are introduced they can be
positive.
* @count is use
2 paths in the domU console handling are now the same. So they can be
merged to make the code simpler.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
Acked-by: Wei Liu
---
Changes in v2:
- Fix indentation
- Add Stefano's reviewed-by
- Add Wei's acked-by
Hi all,
This series contains a bunch of bug fixes for the hypercall CONSOLEIO_write
and some documentation.
Cheers,
Julien Grall (4):
xen/console: Don't treat NUL character as the end of the buffer
xen/console: Rework HYPERCALL_console_io interface
xen/public: Document HYPERCALL_console_io
After upgrading Debian to Buster, I have began to notice console
mangling when using zsh in Dom0. This is happenning because output sent by
zsh to the console may contain NULs in the middle of the buffer.
The actual implementation of CONSOLEIO_write considers that a buffer
always terminate with a
Currently, OS developpers will have to look at Xen code in order to know
the parameters of an hypercall and how it is meant to work.
This is not a trivial task as you may need to have a deep understanding
of Xen internal.
This patch attempts to document the behavior of HYPERCALL_console_io() to
h
On 05.08.2019 15:16, Chao Gao wrote:
> On Mon, Aug 05, 2019 at 10:43:16AM +, Jan Beulich wrote:
>> On 01.08.2019 12:22, Chao Gao wrote:
>>> @@ -283,37 +345,105 @@ static int microcode_update_cpu(const struct
>>> microcode_patch *patch)
>>>return err;
>>>}
>>>
>>> -static long d
On 05.08.2019 15:14, Andrew Cooper wrote:
> On 05/08/2019 13:52, Jan Beulich wrote:
>> On 30.07.2019 16:42, Andrew Cooper wrote:
>>> c/s e9986b0dd "x86/vvmx: Simplify per-CPU memory allocations" had the wrong
>>> indirection on its pointer check in nvmx_cpu_up_prepare(), causing the
>>> VMCS-shadow
On Fri, Jul 19, 2019 at 09:43:26AM +, Jan Beulich wrote:
> On 19.07.2019 11:02, Roger Pau Monné wrote:
> > On Fri, Jul 19, 2019 at 08:04:45AM +, Jan Beulich wrote:
> >> On 18.07.2019 18:52, Roger Pau Monné wrote:
> >>> On Thu, Jul 18, 2019 at 03:17:27PM +, Jan Beulich wrote:
> On
Unfortunately, a parallel build from clean can fail in the following manner:
xen.git$ make -j4 -C tools/firmware/xen-dir/
make: Entering directory '/local/xen.git/tools/firmware/xen-dir'
mkdir -p xen-root
make: *** No rule to make target
'xen-root/xen/arch/x86/configs/pvshim_defconfig', n
flight 139711 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139711/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 133580
test-amd64-i386-exa
flight 139731 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139731/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
Wei Liu writes ("Re: [Xen-devel] [PATCH] tools: ipxe: update for fixing build
with GCC9"):
> On Sat, Jul 27, 2019 at 12:13:49AM +0200, Dario Faggioli wrote:
> > Building with GCC9 (on openSUSE Tubmleweed) generates a lot of errors of
> > the "taking address of packed member of ... may result in an
On 8/5/19 2:19 PM, Jan Beulich wrote:
> On 05.08.2019 15:01, George Dunlap wrote:
>> On 8/5/19 12:55 PM, Jan Beulich wrote:
>>> On 05.08.2019 12:58, George Dunlap wrote:
On 11/26/18 9:31 AM, Jan Beulich wrote:
> +Fixed width types should only be used when a fixed width quantity is
> +m
Support for Intel TXT has orphaned status right now because
no active maintainter is listed. Adding myself as reviewer
and moving it to Odd Fixes state.
Signed-off-by: Lukasz Hawrylko
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
Chao Gao writes ("Re: [PATCH v2] libxl_qmp: wait for completion of device
removal"):
> On Wed, Jul 03, 2019 at 05:03:17PM +0100, Anthony PERARD wrote:
> >On Wed, Jul 03, 2019 at 01:56:13PM +0800, Chao Gao wrote:
> >> To remove a device from a domain, a qmp command is sent to qemu. But it is
> >> h
c/s 986aea7fbe "xl.cfg: add 'cmdline' in config file" introduced cmdline= and
make extra= and root= unusable if cmdline= was present.
For the vm.cfg file itself, this makes sense. However, for development
purposes it is very convenient to have a cmdline= in the cfg file, and specify
extra= on the
Jan Beulich writes ("Re: [PATCH] libacpi: report PCI slots as enabled only for
hotpluggable devices"):
> >>> On 23.05.19 at 17:20, wrote:
> > On Thu, May 23, 2019 at 02:57:49AM -0600, Jan Beulich wrote:
> >> >>> On 22.05.19 at 20:10, wrote:
> >> > DSDT for qemu-xen lacks _STA method of PCI slot
Ian Jackson writes ("Re: [PATCH v2] python: Adjust xc_physinfo wrapper for
updated virt_caps bits"):
> Marek Marczykowski-Górecki writes ("[PATCH v2] python: Adjust xc_physinfo
> wrapper for updated virt_caps bits"):
> > Commit f089fddd94 "xen: report PV capability in sysctl and use it in
> > too
On Mon, Aug 05, 2019 at 03:46:35PM +0100, Ian Jackson wrote:
> Chao Gao writes ("Re: [PATCH v2] libxl_qmp: wait for completion of device
> removal"):
> > On Wed, Jul 03, 2019 at 05:03:17PM +0100, Anthony PERARD wrote:
> > >On Wed, Jul 03, 2019 at 01:56:13PM +0800, Chao Gao wrote:
> > >> To remove
On Mon, Aug 05, 2019 at 03:46:35PM +0100, Ian Jackson wrote:
> From bff0b5dfb692546a12e1f3e124b6691955560112 Mon Sep 17 00:00:00 2001
> From: Ian Jackson
> Date: Mon, 5 Aug 2019 15:44:46 +0100
> Subject: [PATCH RFC]: tools: libxl_qmp: Deprecate synchronous interface
>
> Currently it is not always
On 4/4/19 2:35 PM, Juergen Gross wrote:
> On 04/04/2019 15:27, Wei Liu wrote:
>> On Fri, Mar 15, 2019 at 05:29:28PM +0100, Juergen Gross wrote:
>>> On 15/03/2019 16:55, Andrew Cooper wrote:
On 14/03/2019 11:59, Juergen Gross wrote:
> @@ -1100,6 +1100,20 @@ typedef struct xen_sysctl_cpu_pol
On 05.08.19 17:07, George Dunlap wrote:
On 4/4/19 2:35 PM, Juergen Gross wrote:
On 04/04/2019 15:27, Wei Liu wrote:
On Fri, Mar 15, 2019 at 05:29:28PM +0100, Juergen Gross wrote:
On 15/03/2019 16:55, Andrew Cooper wrote:
On 14/03/2019 11:59, Juergen Gross wrote:
@@ -1100,6 +1100,20 @@ typede
> >> "libxl: fix pci device re-assigning after domain reboot":
> >> commit c19434d9284e93e6f9aaec9a70f5f361adbfaba6
Thanks all. I pushed this to staging-4.12 today.
There are a couple of other things that I say in git log that might
warrant a backport, and for which I'm hoping I get replies qui
At this point nr_frags has been incremented but the frag does not yet
have a page assigned so freeing the skb results in a crash. Reset
nr_frags before freeing the skb to prevent this.
Signed-off-by: Ross Lagerwall
---
drivers/net/xen-netback/netback.c | 2 ++
1 file changed, 2 insertions(+)
di
On Mon, Aug 05, 2019 at 04:19:03PM +0100, Ian Jackson wrote:
> > >> "libxl: fix pci device re-assigning after domain reboot":
> > >> commit c19434d9284e93e6f9aaec9a70f5f361adbfaba6
>
> Thanks all. I pushed this to staging-4.12 today.
>
> There are a couple of other things that I say in git log
On 05.08.2019 16:50, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH] libacpi: report PCI slots as enabled only
> for hotpluggable devices"):
> On 23.05.19 at 17:20, wrote:
>>> On Thu, May 23, 2019 at 02:57:49AM -0600, Jan Beulich wrote:
>>> On 22.05.19 at 20:10, wrote:
> DSDT f
On Mon, Aug 05, 2019 at 03:56:30PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: [PATCH v2] python: Adjust xc_physinfo wrapper for
> updated virt_caps bits"):
> > Marek Marczykowski-Górecki writes ("[PATCH v2] python: Adjust xc_physinfo
> > wrapper for updated virt_caps bits"):
> > > Commi
On 26.07.2019 08:25, Dario Faggioli wrote:
> vcpu_deassign() is called only once (in _vcpu_remove()).
>
> Let's consolidate the two functions into one.
>
> No functional change intended.
>
> Signed-off-by: Dario Faggioli
> Acked-by: George Dunlap
I'm puzzled by commit a397471278, in two ways:
On 8/5/19 4:58 PM, Jan Beulich wrote:
> On 26.07.2019 08:25, Dario Faggioli wrote:
>> vcpu_deassign() is called only once (in _vcpu_remove()).
>>
>> Let's consolidate the two functions into one.
>>
>> No functional change intended.
>>
>> Signed-off-by: Dario Faggioli
>> Acked-by: George Dunlap
>
On 05.08.2019 15:53, Andrew Cooper wrote:
> --- a/tools/firmware/xen-dir/Makefile
> +++ b/tools/firmware/xen-dir/Makefile
> @@ -38,7 +38,7 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES) FORCE
> }
>
> # Copy enough of the tree to build the shim hypervisor
> -$(D): linkfarm.stamp
> +$
flight 139714 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139714/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-libvirt-xsm 7 xen-boot fail in 139691 pass in 139714
test-amd64-i386-qemuu-rhel6hvm-i
On 05.08.2019 17:40, Marek Marczykowski-Górecki wrote:
> On Mon, Aug 05, 2019 at 04:19:03PM +0100, Ian Jackson wrote:
> "libxl: fix pci device re-assigning after domain reboot":
> commit c19434d9284e93e6f9aaec9a70f5f361adbfaba6
>>
>> Thanks all. I pushed this to staging-4.12 today.
>>
>>
On 05/08/2019 17:06, Jan Beulich wrote:
> On 05.08.2019 15:53, Andrew Cooper wrote:
>> --- a/tools/firmware/xen-dir/Makefile
>> +++ b/tools/firmware/xen-dir/Makefile
>> @@ -38,7 +38,7 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES) FORCE
>> }
>>
>> # Copy enough of the tree to build t
Since c/s 9fa94e10585 "x86/ACPI: also parse AMD IOMMU tables early", this
function is unconditionally called in all cases where a DMAR ACPI table
doesn't exist.
As a consequnce, "AMD-Vi: IOMMU not found!" is printed in all cases where an
IOMMU isn't present, even on non-AMD systems. Drop the mess
On Mon, 5 Aug 2019 at 15:30, Ian Jackson wrote:
>
> Wei Liu writes ("Re: [Xen-devel] [PATCH] tools: ipxe: update for fixing build
> with GCC9"):
> > On Sat, Jul 27, 2019 at 12:13:49AM +0200, Dario Faggioli wrote:
> > > Building with GCC9 (on openSUSE Tubmleweed) generates a lot of errors of
> > >
On Sun, Aug 04, 2019 at 03:48:47PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversio
On Mon, 2019-08-05 at 17:04 +0100, George Dunlap wrote:
> On 8/5/19 4:58 PM, Jan Beulich wrote:
> > On 26.07.2019 08:25, Dario Faggioli wrote:
> > >
> > 1) The commit is empty, presumably because I did apply the patch a
> > few
> > days ago already.
> >
> > 2) The committer is recorded as "Patche
On 02/08/2019, 14:36, "Lars Kurth" wrote:
On 02/08/2019, 14:03, "Julien Grall" wrote:
On 02/08/2019 14:02, Julien Grall wrote:
> Hi Jan,
>
> On 02/08/2019 13:52, Jan Beulich wrote:
>> On 02.08.2019 13:14, Lars Kurth
flight 139738 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139738/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 139731
Tests which
flight 139720 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139720/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 139553
Tests which are fail
flight 139729 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139729/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 17a1fc80d578803ae6318e7e297fc0b5605fba29
baseline version:
freebsd f66d5bcdd26
flight 139744 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139744/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-qemuu-rhel6hvm-amd
testid xen-boot
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: ovmf git://xenbits.xen.org/osstest/ovmf.git
flight 139734 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139734/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf aefcf2f78a4800ab64697c7cb334c94b8ea468ae
baseline version:
ovmf 1702e2ce5a5bc2eb4514f
flight 139726 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139726/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
129313
build-armhf-
flight 139728 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139728/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 139687
Tests which did not
98 matches
Mail list logo
