Re: [Xen-devel] Criteria / validation proposal: drop Xen

> On 29. Jul 2019, at 20:58, Ben Cotton wrote: > > On Tue, Jul 23, 2019 at 7:16 PM Adam Williamson > wrote: >> >> OK, so, to move forward with this (and looping in cloud list): does >> someone want to propose a set (ideally small - 2 would be great, one >> Xen and one non-Xen, if we can cover

Re: [Xen-devel] [RFC 5/6] arm64: call enter_hypervisor_head only when it is needed

On 31.07.19 14:02, Julien Grall wrote: Everything is in the hot path here, yet there are a lot of other branches. So why this branch in particular? This branch and function call is particular because I find this piece of code quite confusing: I'm not seeing any benefits in calling `enter_

Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx

On 31.07.2019 21:46, Andrew Cooper wrote: > My bet is on the intel_iommu_lookup_page() call having side effects[1]. > If you take out the debugging in the middle of the loop in > rmrr_identity_mapping(), does the problem reproduce again? While your guess was right according to Roman's latest resul

Re: [Xen-devel] [RFC] xen: Add .astylerc for automated style-formatting

On 31.07.2019 18:20, Viktor Mitin wrote: > How all those projects live without this issue? Perhaps they don't care? I do. > What is the reason not to fix 'diff -p'? Is it not possible at all? I have no idea, but I guess there's a reason for its current behavior. > Could you please share more de

Re: [Xen-devel] [PATCH 3/6] remove late (on-demand) construction of IOMMU page tables

On 30.07.2019 16:44, Paul Durrant wrote: > Now that there is a per-domain IOMMU enable flag, which should be enabled if > any device is going to be passed through, stop deferring page table > construction until the assignment is done. Also don't tear down the tables > again when the last device i

Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx

On Wed, Jul 31, 2019 at 02:03:24PM -0700, Roman Shaposhnik wrote: > On Wed, Jul 31, 2019 at 12:46 PM Andrew Cooper > wrote: > > > > On 31/07/2019 20:35, Roman Shaposhnik wrote: > > > On Wed, Jul 31, 2019 at 1:43 AM Roger Pau Monné > > > wrote: > > >> On Wed, Jul 31, 2019 at 10:36:31AM +0200, Rog

Re: [Xen-devel] [RFC 2/6] schedule: account true system idle time

Hello Dario, On 29.07.19 14:40, Dario Faggioli wrote: Yes, in terms of this patch, idle_vcpu_runstate_change() better be moved to common/schedule.c. I think we should, first of all, think, if using runstates and runstates manipulation functions is really the best way forward here. And, if tha

[Xen-devel] [ovmf test] 139571: all pass - PUSHED

flight 139571 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/139571/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf d21e5dbbbf11589113d39619b3e01eb1e8966819 baseline version: ovmf b3d00df69c78fa0e12986

Re: [Xen-devel] [PATCH v3 1/2] x86/mm: Clean IOMMU flags from p2m-pt code

Hi George, Did you get a chance to look at this clean-up? Thanks, Alex On 16.07.2019 15:01, Alexandru Stefan ISAILA wrote: > At this moment IOMMU pt sharing is disabled by commit [1]. > > This patch aims to clear the IOMMU hap share support as it will not be > used in the future. By doing this

Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx

On Wed, Jul 31, 2019 at 12:30:04PM -0700, Roman Shaposhnik wrote: > On Wed, Jul 31, 2019 at 1:36 AM Roger Pau Monné wrote: > > > > On Tue, Jul 30, 2019 at 10:55:24AM -0700, Roman Shaposhnik wrote: > > > Sorry -- got a bit distracted yesterday. Attached is the log with only > > > your latest patch

Re: [Xen-devel] [RFC 1/6] xen/arm: Re-enable interrupt later in the trap path

Hi, On 01/08/2019 07:45, Andrii Anisov wrote: On 30.07.19 23:10, Julien Grall wrote: In this series I think I need interrupts locked until I start time accounting for hypervisor. Time accounting is started by `tacc_head()` function. I prefer to have it called from C, because it is more conven

[Xen-devel] [xen-unstable test] 139563: tolerable FAIL - PUSHED

flight 139563 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/139563/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 139484 test-amd64-i386-xl-qemuu-win7-amd64

Re: [Xen-devel] [PATCH] CODING_STYLE: clarify function argument indentation

On Wed, Jul 31, 2019 at 05:57:32PM +, Volodymyr Babchuk wrote: > Lars Kurth writes: > > Ultimately we have to make some trade-offs as to what is more important: > > a) automatic style checking - which means "common sense" can't be > > formalised and there will be boundary cases like the above

Re: [Xen-devel] Xen Coding style and clang-format

On Wed, Jul 31, 2019 at 8:05 PM Viktor Mitin wrote: > > On Wed, Jul 31, 2019 at 7:27 PM Lars Kurth wrote: > > > Viktor: thank you for spending time on this > > > > I added an item to community call tomorrow and CC'ed you in the invite. So > > I think what we need to do is figure out a way on how

Re: [Xen-devel] [PATCH] CODING_STYLE: clarify function argument indentation

On 01.08.19 11:55, Anthony PERARD wrote: On Wed, Jul 31, 2019 at 05:57:32PM +, Volodymyr Babchuk wrote: Lars Kurth writes: Ultimately we have to make some trade-offs as to what is more important: a) automatic style checking - which means "common sense" can't be formalised and there will be

[Xen-devel] [PATCH v2 3/4] xen: refactor debugtrace data

As a preparation for per-cpu buffers do a little refactoring of the debugtrace data: put the needed buffer admin data into the buffer as it will be needed for each buffer. While at it switch debugtrace_send_to_console and debugtrace_used to bool and delete an empty line. Signed-off-by: Juergen Gr

[Xen-devel] [PATCH v2 2/4] xen: move debugtrace coding to common/debugtrace.c

Instead of living in drivers/char/console.c move the debugtrace related coding to a new file common/debugtrace.c No functional change, code movement only. Signed-off-by: Juergen Gross --- xen/common/Makefile| 1 + xen/common/debugtrace.c| 177 ++

[Xen-devel] [PATCH v2 0/4] xen: debugtrace cleanup and per-cpu buffer support

Another debugtrace enhancement I needed for core scheduling debugging, plus some cleanup. Changes in V2: - added new patch 1 (preparing the move of debugtrace coding) - patch 4 (v1 patch 3): avoid leaking buffer Juergen Gross (4): xen: use common output function in debugtrace xen: move debugt

[Xen-devel] [PATCH v2 4/4] xen: add per-cpu buffer option to debugtrace

debugtrace is normally writing trace entries into a single trace buffer. There are cases where this is not optimal, e.g. when hunting a bug which requires writing lots of trace entries and one cpu is stuck. This will result in other cpus filling the trace buffer and finally overwriting the interest

[Xen-devel] [PATCH v2 1/4] xen: use common output function in debugtrace

Today dumping the debugtrace buffers is done via sercon_puts(), while direct printing of trace entries (after toggling output to the console) is using serial_puts(). Use sercon_puts() in both cases, as the difference between both is not really making sense. In order to prepare moving debugtrace f

Re: [Xen-devel] [RFC 5/6] arm64: call enter_hypervisor_head only when it is needed

Hi Andrii, On 01/08/2019 08:33, Andrii Anisov wrote: On 31.07.19 14:02, Julien Grall wrote: Everything is in the hot path here, yet there are a lot of other branches. So why this branch in particular? This branch and function call is particular because I find this piece of code quite confu

[Xen-devel] [PATCH v8 00/16] improve late microcode loading

Changes in version 8: - block #NMI handling during microcode loading (Patch 16) - Don't assume that all CPUs in the system have loaded a same ucode. So when parsing a blob, we attempt to save a patch as long as it matches with current cpu signature regardless of the revision of the patch. And

[Xen-devel] [PATCH v8 06/16] microcode: introduce a global cache of ucode patch

to replace the current per-cpu cache 'uci->mc'. With the assumption that all CPUs in the system have the same signature (family, model, stepping and 'pf'), one microcode update matches with one cpu should match with others. Having multiple microcode revisions on different cpus would cause system u

[Xen-devel] [PATCH v8 10/16] microcode/amd: call svm_host_osvw_init() in common code

Introduce a vendor hook, .end_update, for svm_host_osvw_init(). The hook function is called on each cpu after loading an update. It is a preparation for spliting out apply_microcode() from cpu_request_microcode(). Signed-off-by: Chao Gao --- Changes in v8: - new --- xen/arch/x86/microcode.c

[Xen-devel] [PATCH v8 01/16] misc/xen-ucode: Upload a microcode blob to the hypervisor

This patch provides a tool for late microcode update. Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Chao Gao Acked-by: Andrew Cooper --- Changes in v8: - Correct two coding style issues. No functional changes. Changes in v7: - introduce xc_microcode_update() rather than xc_platform_op(

[Xen-devel] [PATCH v8 04/16] microcode/amd: fix memory leak

Two buffers, '->equiv_cpu_table' and '->mpb', inside 'mc_amd' might be allocated and in the error-handing path they are not freed properly. Signed-off-by: Chao Gao --- changes in v8: - new - it is found by reading code. No test is done. --- xen/arch/x86/microcode_amd.c | 14 +++--- 1

[Xen-devel] [PATCH v8 13/16] microcode: unify loading update during CPU resuming and AP wakeup

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 Gao --- Changes in v8: - split out from the pre

[Xen-devel] [PATCH v8 08/16] microcode: remove struct ucode_cpu_info

Remove the per-cpu cache field in struct ucode_cpu_info since it has been replaced by a global cache. It would leads to only one field remaining in ucode_cpu_info. Then, this struct is removed and the remaining field (cpu signature) is stored in per-cpu area. The cpu status notifier is also remove

[Xen-devel] [PATCH v8 02/16] x86/microcode: always collect_cpu_info() during boot

From: Sergey Dyasli Currently cpu_sig struct is not updated during boot if no microcode blob is specified by "ucode=[| scan]". It will result in cpu_sig.rev being 0 which affects APIC's check_deadline_errata() and retpoline_safe() functions. Fix this by getting ucode revision early during boot

[Xen-devel] [PATCH v8 12/16] microcode: split out apply_microcode() from cpu_request_microcode()

During late microcode loading, apply_microcode() is invoked in cpu_request_microcode(). To make late microcode update more reliable, we want to put the apply_microcode() into stop_machine context. So we split out it from cpu_request_microcode(). In general, for both early loading on BSP and late lo

[Xen-devel] [PATCH v8 14/16] x86/microcode: Synchronize late microcode loading

This patch ports microcode improvement patches from linux kernel. Before you read any further: the early loading method is still the preferred one and you should always do that. The following patch is improving the late loading mechanism for long running jobs and cloud use cases. Gather all cores

[Xen-devel] [PATCH v8 07/16] microcode: clean up microcode_resume_cpu

Previously, a per-cpu ucode cache is maintained. Then each CPU had one per-cpu update cache and there might be multiple versions of microcode. Thus microcode_resume_cpu tried best to update microcode by loading every update cache until a successful load. But now the cache struct is simplified a lo

[Xen-devel] [PATCH v8 15/16] microcode: remove microcode_update_lock

microcode_update_lock is to prevent logic threads of a same core from updating microcode at the same time. But due to using a global lock, it also prevented parallel microcode updating on different cores. Remove this lock in order to update microcode in parallel. It is safe because we have already

[Xen-devel] [PATCH v8 11/16] microcode: pass a patch pointer to apply_microcode()

apply_microcode()'s always loading the cached ucode patch forces a patch to be stored before being loading. Make apply_microcode() accept a patch pointer to remove the limitation so that a patch can be stored after a successful loading. Signed-off-by: Chao Gao --- Changes in v8: - new --- xen/a

[Xen-devel] [PATCH v8 16/16] microcode: block #NMI handling when loading an ucode

register an nmi callback. And this callback does busy-loop on threads which are waiting for loading completion if 'loading_ucode' is true. Signed-off-by: Chao Gao --- Changes in v8: - new --- xen/arch/x86/microcode.c | 29 + 1 file changed, 29 insertions(+) diff --g

[Xen-devel] [PATCH v8 05/16] microcode/amd: distinguish old and mismatched ucode in microcode_fits()

Sometimes, an ucode with a level lower than or equal to current CPU's patch level is useful. For example, to work around a broken bios which only loads ucode for BSP, when BSP parses an ucode blob during bootup, it is better to save an ucode with lower or equal level for APs No functional change i

[Xen-devel] [PATCH v8 09/16] microcode: remove pointless 'cpu' parameter

Some callbacks in microcode_ops or related functions take a cpu id parameter. But at current call sites, the cpu id parameter is always equal to current cpu id. Some of them even use an assertion to guarantee this. Remove this redundent 'cpu' parameter. Signed-off-by: Chao Gao --- Changes in v8:

[Xen-devel] [PATCH v8 03/16] microcode/intel: extend microcode_update_match()

to a more generic function. Then, this function can compare two given microcodes' signature/revision as well. Comparing two microcodes is used to update the global microcode cache (introduced by the later patches in this series) when a new microcode is given. Note that enum microcode_match_result

Re: [Xen-devel] [BUG] Assertion failed: !blk->legacy_dev

On Wed, Jul 31, 2019 at 01:11:22PM -0700, Roman Shaposhnik wrote: > Hi! Hi Roman, Thanks for the bug report! That bug (technical debt really) was fixed in QEMU 4.0 (so will be fixed in Xen 4.13). It's a series of patch with the last one been db9ff46 if you want to have a look. > Andrew reminded

Re: [Xen-devel] [PATCH v8 02/16] x86/microcode: always collect_cpu_info() during boot

On 01/08/2019 11:22, Chao Gao wrote: > From: Sergey Dyasli > > Currently cpu_sig struct is not updated during boot if no microcode blob > is specified by "ucode=[| scan]". > > It will result in cpu_sig.rev being 0 which affects APIC's > check_deadline_errata() and retpoline_safe() functions. > > F

Re: [Xen-devel] [RFC 1/6] xen/arm: Re-enable interrupt later in the trap path

On Thu, 2019-08-01 at 09:45 +0300, Andrii Anisov wrote: > Hello Julien, > > On 30.07.19 23:10, Julien Grall wrote: > > > > In this series I think I need interrupts locked until I start > > > time accounting for hypervisor. Time accounting is started by > > > `tacc_head()` function. I prefer to ha

[Xen-devel] [PATCH v5 0/2] xen/arm: Consolidate make_timer_node and make_timer_domU_node

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_

[Xen-devel] [PATCH v5 1/2] xen/arm: extend fdt_property_interrupts to support DomU

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. The new prototype of make_timer_node function is required since make_timer_node calls fdt_property_interrupts which

[Xen-devel] [PATCH v5 2/2] xen/arm: consolidate make_timer_node and make_timer_domU_node

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. Mean do not copy platform's 'compatible

Re: [Xen-devel] [RFC] xen: Add .astylerc for automated style-formatting

On Thu, Aug 1, 2019 at 10:40 AM Jan Beulich wrote: > > On 31.07.2019 18:20, Viktor Mitin wrote: > > How all those projects live without this issue? > > Perhaps they don't care? I do. > > > What is the reason not to fix 'diff -p'? Is it not possible at all? > > I have no idea, but I guess there's a

Re: [Xen-devel] [PATCH v4 1/2] xen/arm: extend fdt_property_interrupts

Hi Julien and Volodymyr, On Wed, Jul 31, 2019 at 3:52 PM Julien Grall wrote: > > Hi, > > >> It is recommended (and probably required, but I can't find exact place > >> in the rules) to include cover letter if you are sending more that one > >> patch in series. This will ease up review process, be

Re: [Xen-devel] [PATCH v4 1/2] xen/arm: extend fdt_property_interrupts

Hi Viktor, On 01/08/2019 13:26, Viktor Mitin wrote: Hi Julien and Volodymyr, On Wed, Jul 31, 2019 at 3:52 PM Julien Grall wrote: Hi, It is recommended (and probably required, but I can't find exact place in the rules) to include cover letter if you are sending more that one patch in series

Re: [Xen-devel] [RFC] xen: Add .astylerc for automated style-formatting

On 01.08.2019 14:16, Viktor Mitin wrote: > I expected you to have some arguments why it cannot be fixed in the > diff or other tools. I don't follow: How does it matter here whether I have arguments towards (not) fixing diff etc? That's their maintainers' arguments, if any, not mine. All I know (f

Re: [Xen-devel] [RFC] xen: Add .astylerc for automated style-formatting

On 01.08.19 14:16, Viktor Mitin wrote: On Thu, Aug 1, 2019 at 10:40 AM Jan Beulich wrote: On 31.07.2019 18:20, Viktor Mitin wrote: How all those projects live without this issue? Perhaps they don't care? I do. What is the reason not to fix 'diff -p'? Is it not possible at all? I have no

[Xen-devel] [linux-4.19 test] 139569: regressions - FAIL

flight 139569 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/139569/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 129313 build-armhf-pvo

Re: [Xen-devel] [PATCH v5 1/2] xen/arm: extend fdt_property_interrupts to support DomU

Hi Viktor, Viktor Mitin writes: > 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. > > The new prototype of make_timer_node function is required > since make

Re: [Xen-devel] [PATCH v5 2/2] xen/arm: consolidate make_timer_node and make_timer_domU_node

Viktor Mitin writes: > 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. > Mean

Re: [Xen-devel] [PATCH v5 1/2] xen/arm: extend fdt_property_interrupts to support DomU

On 01/08/2019 14:33, Volodymyr Babchuk wrote: >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c >> index 4c8404155a..bc7d17dd2c 100644 >> --- a/xen/arch/arm/domain_build.c >> +++ b/xen/arch/arm/domain_build.c >> @@ -621,17 +621,20 @@ static void __init set_interrupt(gic_inte

Re: [Xen-devel] [PATCH v5 2/2] xen/arm: consolidate make_timer_node and make_timer_domU_node

Hi, On 01/08/2019 14:49, Volodymyr Babchuk wrote: Viktor Mitin writes: 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

Re: [Xen-devel] [PATCH v5 2/2] xen/arm: consolidate make_timer_node and make_timer_domU_node

On 01/08/2019 14:57, Julien Grall wrote: Hi, On 01/08/2019 14:49, Volodymyr Babchuk wrote: Viktor Mitin writes: 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 t

Re: [Xen-devel] [PATCH v4 1/2] xen/arm: extend fdt_property_interrupts

> On 1 Aug 2019, at 13:41, Julien Grall wrote: > > Hi Viktor, > > On 01/08/2019 13:26, Viktor Mitin wrote: >> Hi Julien and Volodymyr, >> On Wed, Jul 31, 2019 at 3:52 PM Julien Grall wrote: >>> >>> Hi, >>> > It is recommended (and probably required, but I can't find exact place > in

[Xen-devel] [qemu-mainline test] 139573: regressions - FAIL

flight 139573 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/139573/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail REGR. vs. 139300 Tests

Re: [Xen-devel] [PATCH v4 1/2] xen/arm: extend fdt_property_interrupts

Hi Lars, On 01/08/2019 14:59, Lars Kurth wrote: On 1 Aug 2019, at 13:41, Julien Grall > wrote: Hi Viktor, On 01/08/2019 13:26, Viktor Mitin wrote: Hi Julien and Volodymyr, On Wed, Jul 31, 2019 at 3:52 PM Julien Grall > wrote: Hi,

Re: [Xen-devel] [PATCH v5 2/2] xen/arm: consolidate make_timer_node and make_timer_domU_node

Hi Julien, Julien Grall writes: > Hi, > > On 01/08/2019 14:49, Volodymyr Babchuk wrote: >> >> Viktor Mitin writes: >> >>> 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 functi

[Xen-devel] [Question] Proper location for Linux error code (-EPROBE_DEFER) in Xen

Hello all. What is the proper location to place Linux error code (-EPROBE_DEFER) in Xen? https://elixir.bootlin.com/linux/v5.3-rc2/source/include/linux/errno.h#L19 ... Although that error is going to be used by Arm code the first, I feel it should be somewhere in common place as it is not Arm

Re: [Xen-devel] [PATCH v4 1/2] xen/arm: extend fdt_property_interrupts

> On 1 Aug 2019, at 15:02, Julien Grall wrote: > > Hi Lars, > > On 01/08/2019 14:59, Lars Kurth wrote: >>> On 1 Aug 2019, at 13:41, Julien Grall >> > wrote: >>> >>> Hi Viktor, >>> >>> On 01/08/2019 13:26, Viktor Mitin wrote: Hi Julien and Volodymyr, On

Re: [Xen-devel] [Question] Proper location for Linux error code (-EPROBE_DEFER) in Xen

On Thu, Aug 01, 2019 at 05:10:08PM +0300, Oleksandr wrote: > Hello all. > > What is the proper location to place Linux error code (-EPROBE_DEFER) in > Xen? > https://elixir.bootlin.com/linux/v5.3-rc2/source/include/linux/errno.h#L19 > > ... > Although that error is going to be used by Arm code th

Re: [Xen-devel] [PATCH v5 2/2] xen/arm: consolidate make_timer_node and make_timer_domU_node

Hi Volodymyr, On 01/08/2019 15:07, Volodymyr Babchuk wrote: Hi Julien, Julien Grall writes: Hi, On 01/08/2019 14:49, Volodymyr Babchuk wrote: Viktor Mitin writes: Functions make_timer_node and make_timer_domU_node are quite similar. So it is better to consolidate them to avoid discrepan

Re: [Xen-devel] [Question] Proper location for Linux error code (-EPROBE_DEFER) in Xen

Hello, Hi, Roger I think it would help if you describe why such error code is needed by Xen and how it would be used.  This is needed for the upcoming V2 of the IPMMU driver (ARM) [1] which may request  deferred probing (returns -EPROBE_DEFER) depending on what device will be probed the

Re: [Xen-devel] [Question] Proper location for Linux error code (-EPROBE_DEFER) in Xen

On 01.08.19 17:31, Oleksandr wrote: Hello, Hi, Roger I think it would help if you describe why such error code is needed by Xen and how it would be used.  This is needed for the upcoming V2 of the IPMMU driver (ARM) [1] which may request  deferred probing (returns -EPROBE_DEFER) depend

Re: [Xen-devel] [Question] Proper location for Linux error code (-EPROBE_DEFER) in Xen

On 01.08.2019 16:31, Oleksandr wrote: >  This is needed for the upcoming V2 of the IPMMU driver (ARM) [1] which may > request >  deferred probing (returns -EPROBE_DEFER) depending on what device will be > probed the first >  (Root device must be registered before Cache devices. If not the case

Re: [Xen-devel] [PATCH v5 2/2] xen/arm: consolidate make_timer_node and make_timer_domU_node

Julien Grall writes: > Hi Volodymyr, > > On 01/08/2019 15:07, Volodymyr Babchuk wrote: >> >> Hi Julien, >> >> Julien Grall writes: >> >>> Hi, >>> >>> On 01/08/2019 14:49, Volodymyr Babchuk wrote: Viktor Mitin writes: > Functions make_timer_node and make_timer_domU_node are quit

Re: [Xen-devel] [PATCH v4 1/2] xen/arm: extend fdt_property_interrupts

> > It is not explicitly written in the wiki page. But it is implied in a few > > places such as in the section "Providing a git branch", "Using git > > send-email alone". > > You are right. That should be made explicit. I think you are the only person > in years that sent a series without cover

Re: [Xen-devel] [Question] Proper location for Linux error code (-EPROBE_DEFER) in Xen

On 01.08.19 17:34, Jan Beulich wrote: Hi Jan On 01.08.2019 16:31, Oleksandr wrote:  This is needed for the upcoming V2 of the IPMMU driver (ARM) [1] which may request  deferred probing (returns -EPROBE_DEFER) depending on what device will be probed the first  (Root device must be regi

Re: [Xen-devel] [PATCH] Adding Intel TXT maintainter

> On Jul 29, 2019, at 10:45, Jan Beulich wrote: > >> On 29.07.2019 16:39, Lukasz Hawrylko wrote: >> Support for Intel TXT has orphaned status right now because >> no active maintainter is listed. Adding myself as active maintainter, >> so it could be reverted to supported state. > > Which you sh

[Xen-devel] [ovmf test] 139588: regressions - FAIL

flight 139588 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/139588/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 139571 build-i386-xsm

Re: [Xen-devel] [Question] Proper location for Linux error code (-EPROBE_DEFER) in Xen

On 01.08.2019 16:54, Oleksandr wrote: > On 01.08.19 17:34, Jan Beulich wrote: >> On 01.08.2019 16:31, Oleksandr wrote: >>>    This is needed for the upcoming V2 of the IPMMU driver (ARM) [1] which >>> may request >>>    deferred probing (returns -EPROBE_DEFER) depending on what device will >>> be

Re: [Xen-devel] Xen Coding style and clang-format

On Thu, Aug 1, 2019 at 4:06 AM Viktor Mitin wrote: > > On Wed, Jul 31, 2019 at 8:05 PM Viktor Mitin > wrote: > > > > On Wed, Jul 31, 2019 at 7:27 PM Lars Kurth wrote: > > > > > Viktor: thank you for spending time on this > > > > > > I added an item to community call tomorrow and CC'ed you in th

[Xen-devel] [ANNOUNCE] Xen 4.13 Development Update

This email only tracks big items for xen.git tree. Please reply for items you would like to see in 4.13 so that people have an idea what is going on and prioritise accordingly. You're welcome to provide description and use cases of the feature you're working on. = Timeline = We now adopt a fixed

Re: [Xen-devel] Criteria / validation proposal: drop Xen

On Thu, Aug 1, 2019 at 3:27 AM Elnikety, Eslam wrote: > > But t3 is not Xen. > That's a good reason to not use it. :-) I picked it to be a small, cheap instance that would represent a potential use case. Is the t2 family Xen? Or the m5? I think it makes sense to write the requirement as "the laste

Re: [Xen-devel] Xen Coding style and clang-format

Hi Tamas, On Thu, Aug 1, 2019 at 6:58 PM Tamas K Lengyel wrote: > > On Thu, Aug 1, 2019 at 4:06 AM Viktor Mitin wrote: > > > > On Wed, Jul 31, 2019 at 8:05 PM Viktor Mitin > > wrote: > > > > > > On Wed, Jul 31, 2019 at 7:27 PM Lars Kurth > > > wrote: > > > > > > > Viktor: thank you for spend

Re: [Xen-devel] [PATCH v5 2/2] xen/arm: consolidate make_timer_node and make_timer_domU_node

On Thu, Aug 1, 2019 at 4:58 PM Julien Grall wrote: > > > > On 01/08/2019 14:57, Julien Grall wrote: > >>> +unsigned int irq[MAX_TIMER_PPI]; > >> As I said in the previous version, you are wasting stack space > >> there. Also, this is misleading. When I see array of 4 items, I expect > >> that

Re: [Xen-devel] [ANNOUNCE] Xen 4.13 Development Update

On 01/08/2019 17:00, Juergen Gross wrote: > == Hypervisor == > > * Improvements to domain creation (v2) > - Andrew Cooper This should probably be dropped.  Its not going to get a look in in the forseeable future, and is in the position of gaining incremental improvements anyway. > * Switch

Re: [Xen-devel] [PATCH v5 2/2] xen/arm: consolidate make_timer_node and make_timer_domU_node

On Thu, Aug 1, 2019 at 5:50 PM Volodymyr Babchuk wrote: > >> In this case we also can declare and use intrs[] in the same way. > > > > There is no guarantee the index in irq will match intrs[...]. So you > > need to keep them hardcoded in the latter case. > Oh, right. I don't like the idea of us

[Xen-devel] [libvirt test] 139585: tolerable all pass - PUSHED

flight 139585 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/139585/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 139551 test-armhf-armhf-libvirt-raw 13 saveresto

Re: [Xen-devel] [BUG] Assertion failed: !blk->legacy_dev

On Thu, Aug 1, 2019 at 3:30 AM Anthony PERARD wrote: > > On Wed, Jul 31, 2019 at 01:11:22PM -0700, Roman Shaposhnik wrote: > > Hi! > > Hi Roman, > > Thanks for the bug report! > > That bug (technical debt really) was fixed in QEMU 4.0 (so will be fixed > in Xen 4.13). It's a series of patch with t

Re: [Xen-devel] [BUG] Assertion failed: !blk->legacy_dev

On 01/08/2019 18:35, Roman Shaposhnik wrote: > On Thu, Aug 1, 2019 at 3:30 AM Anthony PERARD > wrote: >> On Wed, Jul 31, 2019 at 01:11:22PM -0700, Roman Shaposhnik wrote: >>> Hi! >> Hi Roman, >> >> Thanks for the bug report! >> >> That bug (technical debt really) was fixed in QEMU 4.0 (so will be

Re: [Xen-devel] [BUG] Assertion failed: !blk->legacy_dev

On Thu, Aug 1, 2019 at 10:44 AM Andrew Cooper wrote: > > On 01/08/2019 18:35, Roman Shaposhnik wrote: > > On Thu, Aug 1, 2019 at 3:30 AM Anthony PERARD > > wrote: > >> On Wed, Jul 31, 2019 at 01:11:22PM -0700, Roman Shaposhnik wrote: > >>> Hi! > >> Hi Roman, > >> > >> Thanks for the bug report!

Re: [Xen-devel] [ANNOUNCE] Xen 4.13 Development Update

On Thu, Aug 1, 2019 at 9:01 AM Juergen Gross wrote: > > This email only tracks big items for xen.git tree. Please reply for items you > would like to see in 4.13 so that people have an idea what is going on and > prioritise accordingly. > > You're welcome to provide description and use cases of th

Re: [Xen-devel] [PATCH v8 00/16] improve late microcode loading

On 01/08/2019 11:22, Chao Gao wrote: > This series includes below changes: > 1. Patch 1: always read microcode revision at boot time > 2. Patch 2: an userspace tool for late microcode update To get things started, I've committed these two changes.  I'm afraid I don't have time immediately to rev

Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx

On Thu, Aug 1, 2019 at 1:45 AM Roger Pau Monné wrote: > > On Wed, Jul 31, 2019 at 12:30:04PM -0700, Roman Shaposhnik wrote: > > On Wed, Jul 31, 2019 at 1:36 AM Roger Pau Monné > > wrote: > > > > > > On Tue, Jul 30, 2019 at 10:55:24AM -0700, Roman Shaposhnik wrote: > > > > Sorry -- got a bit dist

Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx

On Thu, Aug 1, 2019 at 1:16 AM Roger Pau Monné wrote: > > On Wed, Jul 31, 2019 at 02:03:24PM -0700, Roman Shaposhnik wrote: > > On Wed, Jul 31, 2019 at 12:46 PM Andrew Cooper > > wrote: > > > > > > On 31/07/2019 20:35, Roman Shaposhnik wrote: > > > > On Wed, Jul 31, 2019 at 1:43 AM Roger Pau Monn

Re: [Xen-devel] [Question] Proper location for Linux error code (-EPROBE_DEFER) in Xen

On 01.08.19 18:46, Jan Beulich wrote: On 01.08.2019 16:54, Oleksandr wrote: On 01.08.19 17:34, Jan Beulich wrote: On 01.08.2019 16:31, Oleksandr wrote:    This is needed for the upcoming V2 of the IPMMU driver (ARM) [1] which may request    deferred probing (returns -EPROBE_DEFER) dependin

Re: [Xen-devel] [RFC] Generating Go bindings for libxl

> With that said, what are your expectations for the generated Go code at this > point? > Do you think we should try to generate the pieces that call into libxl? Or, > do you think > the code generation should be limited to the structs and boiler-plate C <-> > Go "type > marshaling?" [...] > I

Re: [Xen-devel] Criteria / validation proposal: drop Xen

> On 1. Aug 2019, at 18:27, Ben Cotton wrote: > > On Thu, Aug 1, 2019 at 3:27 AM Elnikety, Eslam wrote: >> >> But t3 is not Xen. >> > That's a good reason to not use it. :-) I picked it to be a small, > cheap instance that would represent a potential use case. Is the t2 > family Xen? Or the

[Xen-devel] [ovmf test] 139600: regressions - FAIL

flight 139600 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/139600/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 139571 build-i386-xsm

[Xen-devel] [linux-linus test] 139584: regressions - FAIL

flight 139584 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/139584/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-

[Xen-devel] [xen-unstable-smoke test] 139607: tolerable all pass - PUSHED

flight 139607 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/139607/ 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

[Xen-devel] [xen-unstable test] 139589: regressions - FAIL

flight 139589 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/139589/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-credit2 7 xen-boot fail REGR. vs. 139563 Tests which did no

Re: [Xen-devel] "CPU N still not dead..." messages during microcode update stage of boot when smt=0

Hi, On Mon, Jul 22, 2019 at 01:06:03PM +0100, Andrew Cooper wrote: > On 22/07/2019 10:16, Jan Beulich wrote: > > On 21.07.2019 22:06, Andy Smith wrote: > >> (XEN) Adding cpu 1 to runqueue 0 > >> (XEN) CPU 1 still not dead... > >> (XEN) CPU 1 still not dead... > >> (XEN) CPU 1 still not dead... > >

[Xen-devel] [PATCH 02/34] net/rds: convert put_page() to put_user_page*()

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 conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder v

[Xen-devel] [PATCH 34/34] fs/binfmt_elf: convert put_page() to put_user_page*()

From: Ira Weiny 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 conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder vers

[Xen-devel] [PATCH 20/34] xen: convert put_page() to put_user_page*()

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 conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder v

[Xen-devel] [PATCH 17/34] vfio: convert put_page() to put_user_page*()

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 conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder v

[Xen-devel] [PATCH 07/34] drm/radeon: convert put_page() to put_user_page*()

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 conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder v

  1   2   >