[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-qemut-ws16-amd64

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemut-ws16-amd64 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

Re: [Xen-devel] [PATCH] p2m/ept: pass correct level to atomic_write_ept_entry in ept_invalidate_emt

> From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: Tuesday, August 20, 2019 11:38 PM > > The level passed to ept_invalidate_emt corresponds to the EPT entry > passed as the mfn parameter, which is a pointer to an EPT page table, > hence the entries in that page table will have one level

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

flight 140527 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/140527/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 1237517b21305ad96834f9a0514a8365dd8a1c41 baseline version: ovmf 9c90d39b600bd33c7e060

Re: [Xen-devel] [PATCH v6 07/10] use is_iommu_enabled() where appropriate...

> From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: Saturday, August 17, 2019 1:20 AM > > ...rather than testing the global iommu_enabled flag and ops pointer. > > Now that there is a per-domain flag indicating whether the domain is > permitted to use the IOMMU (which determines whether

Re: [Xen-devel] [PATCH] x86/vtd: Fix S3 resume following c/s 650c31d3af

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Tuesday, August 13, 2019 1:17 AM > > c/s 650c31d3af "x86/IRQ: fix locking around vector management" adjusted > the > locking in adjust_irq_affinity(). > > The S3 path ends up here via iommu_resume() before interrupts are enabled, >

[Xen-devel] [linux-4.14 test] 140523: regressions - FAIL

flight 140523 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/140523/ 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. 139910 test-amd64-i386-xl

Re: [Xen-devel] [PATCH v2 1/2] x86: define a few selector values

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, August 9, 2019 6:39 PM > > TSS, LDT, and per-CPU entries all can benefit a little from also having > their selector values defined. > > Signed-off-by: Jan Beulich Reviewed-by: Kevin Tian

Re: [Xen-devel] [PATCH] x86/vvmx: Fix nested virt on VMCS-Shadow capable hardware

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Tuesday, July 30, 2019 10:43 PM > > 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. F

Re: [Xen-devel] More questions about Xen memory layout/usage, access to guest memory

On Thu, Aug 22, 2019 at 6:03 PM Andrew Cooper wrote: > > On 23/08/2019 00:06, Tamas K Lengyel wrote: > > On Thu, Aug 22, 2019 at 4:40 PM Andrew Cooper > > wrote: > >> On 22/08/2019 21:57, Rich Persaud wrote: > On Aug 22, 2019, at 09:51, Andrew Cooper > wrote: > > > On 22/08/

Re: [Xen-devel] [PATCH v3 27/28] xen/arm32: head: Introduce macros to create table and mapping entry

On Mon, 12 Aug 2019, Julien Grall wrote: > At the moment, any update to the boot-pages are open-coded. This is > making more difficult to understand the logic of a function as each > update roughly requires 6 instructions. > > To ease the readability, two new macros are introduced: > - create_

Re: [Xen-devel] More questions about Xen memory layout/usage, access to guest memory

On 23/08/2019 00:06, Tamas K Lengyel wrote: > On Thu, Aug 22, 2019 at 4:40 PM Andrew Cooper > wrote: >> On 22/08/2019 21:57, Rich Persaud wrote: On Aug 22, 2019, at 09:51, Andrew Cooper wrote: > On 22/08/2019 03:06, Johnson, Ethan wrote: > > For HVM, obviously anything that

Re: [Xen-devel] [PATCH v3 25/28] xen/arm64: head: Introduce macros to create table and mapping entry

On Fri, 23 Aug 2019, 00:33 Stefano Stabellini, wrote: > On Mon, 12 Aug 2019, Julien Grall wrote: > > At the moment, any update to the boot-pages are open-coded. This is > > making more difficult to understand the logic of a function as each > > update roughly requires 6 instructions. > > > > To e

Re: [Xen-devel] [PATCH v3 20/28] xen/arm32: head: Remove 1:1 mapping as soon as it is not used

Sorry for the formatting. On Thu, 22 Aug 2019, 23:55 Stefano Stabellini, wrote: > On Thu, 22 Aug 2019, Julien Grall wrote: > > > >*/ > > > > -dsb > > > > +lsr r1, r9, #FIRST_SHIFT > > > > +mov_w r0, LPAE_ENTRY_MASK > > > > > > ldr? > > > > What's wrong with

Re: [Xen-devel] [PATCH v3 25/28] xen/arm64: head: Introduce macros to create table and mapping entry

On Mon, 12 Aug 2019, Julien Grall wrote: > At the moment, any update to the boot-pages are open-coded. This is > making more difficult to understand the logic of a function as each > update roughly requires 6 instructions. > > To ease the readability, two new macros are introduced: > - create_

Re: [Xen-devel] More questions about Xen memory layout/usage, access to guest memory

On Thu, Aug 22, 2019 at 4:40 PM Andrew Cooper wrote: > > On 22/08/2019 21:57, Rich Persaud wrote: > >> On Aug 22, 2019, at 09:51, Andrew Cooper wrote: > >> > >>> On 22/08/2019 03:06, Johnson, Ethan wrote: > >>> > >>> For HVM, obviously anything that can't be virtualized natively by the > >>> hard

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

flight 140495 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/140495/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 6 kernel-build fail REGR. vs. 129313 Tests which are fail

Re: [Xen-devel] [PATCH v3 20/28] xen/arm32: head: Remove 1:1 mapping as soon as it is not used

On Thu, 22 Aug 2019, Julien Grall wrote: > > >*/ > > > -dsb > > > +lsr r1, r9, #FIRST_SHIFT > > > +mov_w r0, LPAE_ENTRY_MASK > > > > ldr? > > What's wrong with the mov_w? Ok it is two instructions but... the constant > will be stored in a literal and therefor

Re: [Xen-devel] More questions about Xen memory layout/usage, access to guest memory

On 22/08/2019 18:36, Tamas K Lengyel wrote: >>> I've found a number of files in the Xen source tree which seem to be >>> related to instruction/x86 platform emulation: >>> >>> arch/x86/x86_emulate.c >>> arch/x86/hvm/emulate.c >>> arch/x86/hvm/vmx/realmode.c >>> arch/x86/hvm/svm/emulate.c >>> arch/x

Re: [Xen-devel] More questions about Xen memory layout/usage, access to guest memory

On 22/08/2019 16:06, Rian Quinn wrote: > I can at least confirm that no emulation is needed to execute a Linux > guest, even with the Xen PVH interface, but I don't think that works > out of the box today with Xen, something we are currently working on > and will hopefully have some more data near

Re: [Xen-devel] More questions about Xen memory layout/usage, access to guest memory

On 22/08/2019 21:57, Rich Persaud wrote: >> On Aug 22, 2019, at 09:51, Andrew Cooper wrote: >> >>> On 22/08/2019 03:06, Johnson, Ethan wrote: >>> >>> For HVM, obviously anything that can't be virtualized natively by the >>> hardware needs to be emulated by Xen/QEMU (since the guest kernel isn't

Re: [Xen-devel] [PATCH 14/14] livepatch: Add python bindings for livepatch operations

On Wed, Aug 21, 2019 at 08:19:31AM +, Pawel Wieczorkiewicz wrote: > Extend the XC python bindings library to support also all common > livepatch operations and actions. > > Add the python bindings for the following operations: > - status (pyxc_livepatch_status): > Requires a payload name as

[Xen-devel] [libvirt test] 140510: regressions - FAIL

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

Re: [Xen-devel] More questions about Xen memory layout/usage, access to guest memory

> On Aug 22, 2019, at 09:51, Andrew Cooper wrote: > >> On 22/08/2019 03:06, Johnson, Ethan wrote: >> >> For HVM, obviously anything that can't be virtualized natively by the >> hardware needs to be emulated by Xen/QEMU (since the guest kernel isn't >> expected to be cooperative to issue PV hyp

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

flight 140502 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/140502/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 140282 Tests which did n

[Xen-devel] [linux-4.4 test] 140490: regressions - FAIL

flight 140490 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/140490/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 140072 REGR. vs. 139698 Tests which

Re: [Xen-devel] [PATCH v3 20/28] xen/arm32: head: Remove 1:1 mapping as soon as it is not used

Hi Stefano, On 8/22/19 7:17 PM, Stefano Stabellini wrote: On Mon, 12 Aug 2019, Julien Grall wrote: The 1:1 mapping may clash with other parts of the Xen virtual memory layout. At the moment, Xen is handling the clash by only creating a mapping to the runtime virtual address before enabling the

Re: [Xen-devel] [PATCH v3 02/28] xen/arm64: head: Remove 1:1 mapping as soon as it is not used

On Thu, 22 Aug 2019, Julien Grall wrote: > Hi Stefano, > > On 8/22/19 6:58 PM, Stefano Stabellini wrote: > > On Mon, 12 Aug 2019, Julien Grall wrote: > > > The 1:1 mapping may clash with other parts of the Xen virtual memory > > > layout. At the moment, Xen is handling the clash by only creating a

Re: [Xen-devel] [PATCH v3 02/28] xen/arm64: head: Remove 1:1 mapping as soon as it is not used

Hi Stefano, On 8/22/19 6:58 PM, Stefano Stabellini wrote: On Mon, 12 Aug 2019, Julien Grall wrote: The 1:1 mapping may clash with other parts of the Xen virtual memory layout. At the moment, Xen is handling the clash by only creating a mapping to the runtime virtual address before enabling the

Re: [Xen-devel] [PATCH v3 20/28] xen/arm32: head: Remove 1:1 mapping as soon as it is not used

On Mon, 12 Aug 2019, Julien Grall wrote: > The 1:1 mapping may clash with other parts of the Xen virtual memory > layout. At the moment, Xen is handling the clash by only creating a > mapping to the runtime virtual address before enabling the MMU. > > The rest of the mappings (such as the fixmap)

Re: [Xen-devel] [PATCH] [RFC] xen/arm: Restrict "pa_range" according to the IOMMU requirements

On 8/22/19 6:06 PM, Oleksandr wrote: On 22.08.19 15:46, Julien Grall wrote: Hi Oleksandr, Hi Julien. Hi, On 21/08/2019 19:17, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko There is a strict requirement for the IOMMU which wants to share the P2M table with the CPU. The maxi

Re: [Xen-devel] [PATCH v3 02/28] xen/arm64: head: Remove 1:1 mapping as soon as it is not used

On Mon, 12 Aug 2019, Julien Grall wrote: > The 1:1 mapping may clash with other parts of the Xen virtual memory > layout. At the moment, Xen is handling the clash by only creating a > mapping to the runtime virtual address before enabling the MMU. > > The rest of the mappings (such as the fixmap)

Re: [Xen-devel] More questions about Xen memory layout/usage, access to guest memory

> > I've found a number of files in the Xen source tree which seem to be > > related to instruction/x86 platform emulation: > > > > arch/x86/x86_emulate.c > > arch/x86/hvm/emulate.c > > arch/x86/hvm/vmx/realmode.c > > arch/x86/hvm/svm/emulate.c > > arch/x86/pv/emulate.c > > arch/x86/pv/emul-priv-op

Re: [Xen-devel] [PATCH v3 18/28] xen/arm32: head: Move assembly switch to the runtime PT in secondary CPUs path

On Mon, 12 Aug 2019, Julien Grall wrote: > The assembly switch to the runtime PT is only necessary for the > secondary CPUs. So move the code in the secondary CPUs path. > > While this is definitely not compliant with the Arm Arm as we are > switching between two differents set of page-tables with

Re: [Xen-devel] [PATCH v3 23/28] xen/arm32: head: Setup HTTBR in enable_mmu() and add missing isb

On Mon, 12 Aug 2019, Julien Grall wrote: > At the moment, HTTBR is setup in create_page_tables(). This is fine as > it is called by every CPUs. > > However, such assumption may not hold in the future. To make change > easier, the HTTBR is not setup in enable_mmu(). > > Take the opportunity to add

Re: [Xen-devel] [PATCH v3 14/28] xen/arm32: head: Rework and document check_cpu_mode()

On Mon, 12 Aug 2019, Julien Grall wrote: > A branch in the success case can be avoided by inverting the branch > condition. At the same time, remove a pointless comment as Xen can only > run at Hypervisor Mode. > > Lastly, document the behavior and the main registers usage within the > function. >

Re: [Xen-devel] [PATCH v3 13/28] xen/arm32: head: Introduce distinct paths for the boot CPU and secondary CPUs

On Mon, 12 Aug 2019, Julien Grall wrote: > The boot code is currently quite difficult to go through because of the > lack of documentation and a number of indirection to avoid executing > some path in either the boot CPU or secondary CPUs. > > In an attempt to make the boot code easier to follow,

Re: [Xen-devel] [PATCH v3 07/28] xen/arm64: head: Fix typo in the documentation on top of init_uart()

On Mon, 12 Aug 2019, Julien Grall wrote: > Signed-off-by: Julien Grall Acked-by: Stefano Stabellini > --- > Changes in v3: > - Patch added > --- > xen/arch/arm/arm64/head.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/arch/arm/arm64/head.S b/xen/ar

Re: [Xen-devel] [PATCH v3 01/28] xen/arm: lpae: Allow more LPAE helpers to be used in assembly

On Mon, 12 Aug 2019, Julien Grall wrote: > A follow-up patch will require to use *_table_offset() and *_MASK helpers > from assembly. This can be achieved by using _AT() macro to remove the type > when called from assembly. > > Signed-off-by: Julien Grall Acked-by: Stefano Stabellini > --- >

Re: [Xen-devel] [PATCH] [RFC] xen/arm: Restrict "pa_range" according to the IOMMU requirements

On 22.08.19 15:46, Julien Grall wrote: Hi Oleksandr, Hi Julien. Thank you for the review. Please try to get your patch on the latest Xen before sending it. So you can get the right people CCed. For instance, Volodymyr has not been CCed as a reviewer. Ooh, next time will do. Sorry for

Re: [Xen-devel] [PATCH v9 11/15] microcode: unify loading update during CPU resuming and AP wakeup

On Thu, Aug 22, 2019 at 04:10:46PM +0200, Roger Pau Monné wrote: >On Mon, Aug 19, 2019 at 09:25:24AM +0800, 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 d

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

flight 140486 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/140486/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 16 guest-localmigrate fail REGR. vs. 139876 build-amd64-xsm

Re: [Xen-devel] [PATCH 09/14] livepatch: Add per-function applied/reverted state tracking marker

On 22. Aug 2019, at 17:30, Julien Grall mailto:julien.gr...@arm.com>> wrote: Hi Pawel, On 22/08/2019 12:02, Wieczorkiewicz, Pawel wrote: On 22. Aug 2019, at 12:29, Julien Grall mailto:julien.gr...@arm.com> > wrote: On 21/08/2019 09:19, Pawel Wieczorkiewicz wrote:

Re: [Xen-devel] [PATCH v9 00/15] improve late microcode loading

On Thu, Aug 22, 2019 at 08:51:43AM +0100, Sergey Dyasli wrote: >Hi Chao, > >On 19/08/2019 02:25, Chao Gao wrote: >> Previous change log: >> 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. >>

Re: [Xen-devel] [PATCH 09/14] livepatch: Add per-function applied/reverted state tracking marker

Hi Pawel, On 22/08/2019 12:02, Wieczorkiewicz, Pawel wrote: On 22. Aug 2019, at 12:29, Julien Grall > wrote: On 21/08/2019 09:19, Pawel Wieczorkiewicz wrote: More generally, I am not very comfortable to see panic() in the middle of the code. Could you explain why pa

Re: [Xen-devel] More questions about Xen memory layout/usage, access to guest memory

I can at least confirm that no emulation is needed to execute a Linux guest, even with the Xen PVH interface, but I don't think that works out of the box today with Xen, something we are currently working on and will hopefully have some more data near the end of the year. x2APIC helps, but it takes

Re: [Xen-devel] [PATCH 09/14] livepatch: Add per-function applied/reverted state tracking marker

Hi, On 22/08/2019 12:15, Wieczorkiewicz, Pawel wrote: On 22. Aug 2019, at 12:43, Julien Grall > wrote: On 22/08/2019 11:20, Wieczorkiewicz, Pawel wrote: Cross-compiler are nowadays widely available. So build testing your changes in common code would be the minimum.

Re: [Xen-devel] [PATCH 1/2] xen-bus: Fix backend state transition on device reset

On Thu, Aug 22, 2019 at 10:59:38AM +0100, Paul Durrant wrote: > > -Original Message- > > From: Anthony PERARD > > Sent: 22 August 2019 10:51 > > To: Paul Durrant > > Cc: qemu-de...@nongnu.org; qemu-sta...@nongnu.org; Stefano Stabellini > > ; xen- > > de...@lists.xenproject.org > > Subjec

Re: [Xen-devel] [PATCH v9 11/15] microcode: unify loading update during CPU resuming and AP wakeup

On Mon, Aug 19, 2019 at 09:25:24AM +0800, 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. > >

Re: [Xen-devel] [PATCH 13/20] create-diff-object: Strip all undefined entires of known size

On 8/21/19 9:20 AM, Pawel Wieczorkiewicz wrote: The patched ELF object file contains all sections and symbols as resulted from the compilation. However, certain symbols may not be copied over to the resulting object file, due to being unchanged or not included for other reasons. In such situation

[Xen-devel] [PATCH v2] x86/mm: Add mem access rights to NPT

This patch adds access control for NPT mode. The access rights are stored in the NPT p2m table 56:53. The bits are free after clearing the IOMMU flags [1]. Modify p2m_type_to_flags() to accept and interpret an access value, parallel to the ept code. Add a set_default_access() method to the p2m-p

Re: [Xen-devel] [PATCH v9 10/15] microcode: split out apply_microcode() from cpu_request_microcode()

On Mon, Aug 19, 2019 at 09:25:23AM +0800, Chao Gao wrote: > 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_

Re: [Xen-devel] [PATCH 12/20] create-diff-object: Extend patchability verification: STN_UNDEF

On 8/21/19 9:20 AM, Pawel Wieczorkiewicz wrote: During verification check if all sections do not contain any entries with undefined symbols (STN_UNDEF). This situation can happen when a section is copied over from its original object to a patched object, but various symbols related to the section

Re: [Xen-devel] More questions about Xen memory layout/usage, access to guest memory

On 22/08/2019 03:06, Johnson, Ethan wrote: > On 8/17/2019 7:04 AM, Andrew Cooper wrote: >>> Similarly, to what extent does the dom0 (or other such >>> privileged domain) utilize "foreign memory maps" to reach into another >>> guest's memory? I understand that this is necessary when creating a >>> g

Re: [Xen-devel] [PATCH 2/2] xen-bus: Avoid rewriting identical values to xenstore

> -Original Message- > From: Anthony PERARD > Sent: 22 August 2019 14:18 > To: Paul Durrant > Cc: qemu-de...@nongnu.org; Stefano Stabellini ; > xen-devel@lists.xenproject.org > Subject: Re: [PATCH 2/2] xen-bus: Avoid rewriting identical values to xenstore > > On Thu, Aug 22, 2019 at 12:

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

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

Re: [Xen-devel] [PATCH 2/2] xen-bus: Avoid rewriting identical values to xenstore

On Thu, Aug 22, 2019 at 12:25:44PM +0100, Paul Durrant wrote: > > From: Anthony PERARD > > Sent: 22 August 2019 12:18 > > > > On Thu, Aug 22, 2019 at 11:36:32AM +0100, Paul Durrant wrote: > > > But, now I look at the code again without your patch applied I don't > > > actually see the problem it

Re: [Xen-devel] [PATCH 11/20] create-diff-object: Do not create empty .livepatch.funcs section

On 8/21/19 9:20 AM, Pawel Wieczorkiewicz wrote: When there is no changed function in the generated payload, do not create an empty .livepatch.funcs section. Hypervisor code considers such payloads as broken and rejects to load them. Such payloads without any changed functions may appear when onl

Re: [Xen-devel] [PATCH 10/20] create-diff-object: Do not include all .rodata sections

On 8/21/19 9:20 AM, Pawel Wieczorkiewicz wrote: Older versions of GCC did not split .rodata.str sections by function. Because of that, the entire section was always included. The livepatch-build-tools commit [1] fixed patch creation and kept including all .rodata.str sections, in order to maintai

Re: [Xen-devel] [PATCH 09/20] create-diff-object: Add new entries to special sections array

On 8/21/19 9:20 AM, Pawel Wieczorkiewicz wrote: Handle .livepatch.hooks* and .altinstr_replacement sections as the special sections with assigned group_size resolution function. By default each .livepatch.hooks* sections' entry is 8 bytes long (a pointer). The .altinstr_replacement section has un

Re: [Xen-devel] [PATCH v9 08/15] microcode/amd: call svm_host_osvw_init() in common code

On Mon, Aug 19, 2019 at 09:25:21AM +0800, Chao Gao wrote: > 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(). > > Note that svm_

Re: [Xen-devel] [PATCH 7/7] ioreq: provide support for long-running operations...

> -Original Message- > From: Roger Pau Monne > Sent: 22 August 2019 13:55 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; Jan Beulich ; Andrew > Cooper > ; Wei Liu ; George Dunlap > ; Ian > Jackson ; Julien Grall ; Konrad > Rzeszutek Wilk > ; Stefano Stabellini ; Tim > (Xen

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

flight 140477 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/140477/ 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. 133580 test-amd64-i386-xl-

Re: [Xen-devel] [PATCH 7/7] ioreq: provide support for long-running operations...

On Thu, Aug 22, 2019 at 11:15:50AM +0200, Paul Durrant wrote: > > -Original Message- > > From: Roger Pau Monne > > Sent: 21 August 2019 15:59 > > To: xen-devel@lists.xenproject.org > > Cc: Roger Pau Monne ; Paul Durrant > > ; Jan Beulich > > ; Andrew Cooper ; Wei Liu > > ; George Dunlap

Re: [Xen-devel] [PATCH] [RFC] xen/arm: Restrict "pa_range" according to the IOMMU requirements

Hi Oleksandr, Please try to get your patch on the latest Xen before sending it. So you can get the right people CCed. For instance, Volodymyr has not been CCed as a reviewer. On 21/08/2019 19:17, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko There is a strict requirement for the IO

[Xen-devel] [linux-4.14 test] 140478: regressions - FAIL

flight 140478 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/140478/ 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. 139910 test-amd64-i386-xl

Re: [Xen-devel] [PATCH 2/2] xen-bus: Avoid rewriting identical values to xenstore

> -Original Message- > From: Anthony PERARD > Sent: 22 August 2019 12:18 > To: Paul Durrant > Cc: qemu-de...@nongnu.org; Stefano Stabellini ; > xen-devel@lists.xenproject.org > Subject: Re: [PATCH 2/2] xen-bus: Avoid rewriting identical values to xenstore > > On Thu, Aug 22, 2019 at 11:

Re: [Xen-devel] [PATCH 2/2] xen-bus: Avoid rewriting identical values to xenstore

On Thu, Aug 22, 2019 at 11:36:32AM +0100, Paul Durrant wrote: > But, now I look at the code again without your patch applied I don't actually > see the problem it is trying to fix. The functions > xen_device_[back|front]end_set_state return early if the state being set > matches the existing sta

Re: [Xen-devel] [PATCH 09/14] livepatch: Add per-function applied/reverted state tracking marker

On 22. Aug 2019, at 12:43, Julien Grall mailto:julien.gr...@arm.com>> wrote: Hi, On 22/08/2019 11:20, Wieczorkiewicz, Pawel wrote: ..snip.. Cross-compiler are nowadays widely available. So build testing your changes in common code would be the minimum. I wish it was that simple. Neverthel

Re: [Xen-devel] [PATCH v9 04/15] microcode: introduce a global cache of ucode patch

On Mon, Aug 19, 2019 at 09:25:17AM +0800, Chao Gao wrote: > 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

Re: [Xen-devel] [PATCH 10/14] livepatch: Add support for inline asm hotpatching expectations

On 22. Aug 2019, at 12:31, Julien Grall mailto:julien.gr...@arm.com>> wrote: Hi Pawel, On 21/08/2019 09:19, Pawel Wieczorkiewicz wrote: diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h index b55ad6d050..e18322350d 100644 --- a/xen/include/public/sysctl.h +++ b/xen/include

Re: [Xen-devel] [PATCH 09/14] livepatch: Add per-function applied/reverted state tracking marker

On 22. Aug 2019, at 12:29, Julien Grall mailto:julien.gr...@arm.com>> wrote: Hi Pawel, Hi Julien, Thank for looking at this! On 21/08/2019 09:19, Pawel Wieczorkiewicz wrote: Livepatch only tracks an entire payload applied/reverted state. But, with an option to supply the apply_payload() and

Re: [Xen-devel] [PATCH 09/14] livepatch: Add per-function applied/reverted state tracking marker

Hi, On 22/08/2019 11:20, Wieczorkiewicz, Pawel wrote: On 22. Aug 2019, at 12:07, Julien Grall > wrote: On 22/08/2019 08:44, Wieczorkiewicz, Pawel wrote: diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h index 2aec532ee2..a93126f631 100644 --- a/

Re: [Xen-devel] [PATCH 2/2] xen-bus: Avoid rewriting identical values to xenstore

> -Original Message- > From: Anthony PERARD > Sent: 22 August 2019 11:22 > To: Paul Durrant > Cc: qemu-de...@nongnu.org; Stefano Stabellini ; > xen-devel@lists.xenproject.org > Subject: Re: [PATCH 2/2] xen-bus: Avoid rewriting identical values to xenstore > > On Wed, Aug 21, 2019 at 04:

Re: [Xen-devel] [PATCH 10/14] livepatch: Add support for inline asm hotpatching expectations

Hi Pawel, On 21/08/2019 09:19, Pawel Wieczorkiewicz wrote: diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h index b55ad6d050..e18322350d 100644 --- a/xen/include/public/sysctl.h +++ b/xen/include/public/sysctl.h @@ -818,7 +818,7 @@ struct xen_sysctl_cpu_featureset { *

Re: [Xen-devel] [PATCH 09/14] livepatch: Add per-function applied/reverted state tracking marker

Hi Pawel, On 21/08/2019 09:19, Pawel Wieczorkiewicz wrote: Livepatch only tracks an entire payload applied/reverted state. But, with an option to supply the apply_payload() and/or revert_payload() functions as optional hooks, it becomes possible to intermix the execution of the original apply_pa

Re: [Xen-devel] [PATCH 2/2] xen-bus: Avoid rewriting identical values to xenstore

On Wed, Aug 21, 2019 at 04:40:05PM +0100, Paul Durrant wrote: > > -Original Message- > > From: Anthony PERARD > > Sent: 21 August 2019 10:20 > > To: qemu-de...@nongnu.org > > Cc: Anthony Perard ; Stefano Stabellini > > ; Paul > > Durrant ; xen-devel@lists.xenproject.org > > Subject: [PATC

Re: [Xen-devel] [PATCH 09/14] livepatch: Add per-function applied/reverted state tracking marker

On 22. Aug 2019, at 12:07, Julien Grall mailto:julien.gr...@arm.com>> wrote: Hi, On 22/08/2019 08:44, Wieczorkiewicz, Pawel wrote: …snip... Is this going to break livepatch on Arm? If so, do you have any plan to fix it? No, I do not think it is. But, I am unable to test on Arm (No access t

Re: [Xen-devel] [PATCH 09/14] livepatch: Add per-function applied/reverted state tracking marker

Hi, On 22/08/2019 08:44, Wieczorkiewicz, Pawel wrote: On 21. Aug 2019, at 23:34, Julien Grall > wrote: On 8/21/19 9:19 AM, Pawel Wieczorkiewicz wrote: Livepatch only tracks an entire payload applied/reverted state. But, with an option to supply the apply_payload()

Re: [Xen-devel] [PATCH 1/2] xen-bus: Fix backend state transition on device reset

> -Original Message- > From: Anthony PERARD > Sent: 22 August 2019 10:51 > To: Paul Durrant > Cc: qemu-de...@nongnu.org; qemu-sta...@nongnu.org; Stefano Stabellini > ; xen- > de...@lists.xenproject.org > Subject: Re: [PATCH 1/2] xen-bus: Fix backend state transition on device reset > >

Re: [Xen-devel] [PATCH 1/2] xen-bus: Fix backend state transition on device reset

On Wed, Aug 21, 2019 at 10:36:40AM +0100, Paul Durrant wrote: > > diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c > > index e40500242d..982eca4533 100644 > > --- a/hw/xen/xen-bus.c > > +++ b/hw/xen/xen-bus.c > > @@ -540,9 +540,11 @@ static void xen_device_backend_changed(void *opaque) > > /*

Re: [Xen-devel] [PATCH 7/7] ioreq: provide support for long-running operations...

> -Original Message- > From: Roger Pau Monne > Sent: 21 August 2019 15:59 > To: xen-devel@lists.xenproject.org > Cc: Roger Pau Monne ; Paul Durrant > ; Jan Beulich > ; Andrew Cooper ; Wei Liu > ; George Dunlap > ; Ian Jackson ; Julien > Grall ; > Konrad Rzeszutek Wilk ; Stefano Stabelli

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

flight 140513 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/140513/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 1

Re: [Xen-devel] [PATCH 4/7] ioreq: allow registering internal ioreq server handler

> -Original Message- > From: Roger Pau Monne > Sent: 22 August 2019 08:44 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; Jan Beulich ; Andrew > Cooper > ; Wei Liu > Subject: Re: [PATCH 4/7] ioreq: allow registering internal ioreq server > handler > > On Wed, Aug 21, 2019 at

Re: [Xen-devel] [PATCH 3/7] ioreq: allow dispatching ioreqs to internal servers

> -Original Message- > From: Roger Pau Monne > Sent: 22 August 2019 08:41 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; Jan Beulich ; Andrew > Cooper > ; Wei Liu > Subject: Re: [PATCH 3/7] ioreq: allow dispatching ioreqs to internal servers > > On Wed, Aug 21, 2019 at 06:29:

Re: [Xen-devel] [PATCH 2/7] ioreq: add internal ioreq initialization support

> -Original Message- > From: Roger Pau Monne > Sent: 22 August 2019 08:24 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; Jan Beulich ; Andrew > Cooper > ; Wei Liu > Subject: Re: [PATCH 2/7] ioreq: add internal ioreq initialization support > > On Wed, Aug 21, 2019 at 06:24:17P

Re: [Xen-devel] [PATCH v9 00/15] improve late microcode loading

Hi Chao, On 19/08/2019 02:25, Chao Gao wrote: > Previous change log: > 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 matc

[Xen-devel] [linux-next test] 140467: tolerable FAIL

flight 140467 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/140467/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail blocked in 140428 test-armhf-armhf-libvirt-raw 13 savere

Re: [Xen-devel] [PATCH 09/14] livepatch: Add per-function applied/reverted state tracking marker

On 21. Aug 2019, at 23:34, Julien Grall mailto:julien.gr...@arm.com>> wrote: Hi Pawel, Hi Julien, On 8/21/19 9:19 AM, Pawel Wieczorkiewicz wrote: Livepatch only tracks an entire payload applied/reverted state. But, with an option to supply the apply_payload() and/or revert_payload() functions

Re: [Xen-devel] [PATCH 4/7] ioreq: allow registering internal ioreq server handler

On Wed, Aug 21, 2019 at 06:35:15PM +0200, Paul Durrant wrote: > > -Original Message- > > From: Roger Pau Monne > > Sent: 21 August 2019 15:59 > > To: xen-devel@lists.xenproject.org > > Cc: Roger Pau Monne ; Paul Durrant > > ; Jan Beulich > > ; Andrew Cooper ; Wei Liu > > > > Subject: [P

Re: [Xen-devel] [PATCH 3/7] ioreq: allow dispatching ioreqs to internal servers

On Wed, Aug 21, 2019 at 06:29:04PM +0200, Paul Durrant wrote: > > -Original Message- > > From: Roger Pau Monne > > Sent: 21 August 2019 15:59 > > To: xen-devel@lists.xenproject.org > > Cc: Roger Pau Monne ; Paul Durrant > > ; Jan Beulich > > ; Andrew Cooper ; Wei Liu > > > > Subject: [P

Re: [Xen-devel] [PATCH 2/7] ioreq: add internal ioreq initialization support

On Wed, Aug 21, 2019 at 06:24:17PM +0200, Paul Durrant wrote: > > -Original Message- > > From: Roger Pau Monne > > Sent: 21 August 2019 15:59 > > To: xen-devel@lists.xenproject.org > > Cc: Roger Pau Monne ; Jan Beulich > > ; Andrew Cooper > > ; Wei Liu ; Paul Durrant > > > > Subject: [P